Defining an OAuth Profile¶
To use the OAuth profile, it needs to be defined. The OAuth profile consists of the multiple components, which are described in more detail in their appropriate section:
- Configuring OAuth User Authentication
- OAuth Client Configuration
- Scopes and Claims
- OpenID Connect
- Issuing OAuth and OpenId Connect Tokens
The OAuth Profile defines the following endpoints
- The Authorize endpoint
- The Token endpoint
- The Introspection endpoint
- The Revocation endpoint
- The Token Exchange endpoint
- The OAuth 2.0 Token Exchange endpoint
- The Assisted Token endpoint
- The Anonymous endpoint
- Dynamic client registration endpoint
- Device Flow endpoint
See the Developer guide about how to use these.
Note
All endpoints are configurable, and based on how OAuth needs to be deployed, it is possible to enable or disable the different endpoints as needed.
Preparing the OAuth Profile¶
One central part of the OAuth profile is issuing tokens, which Curity does through so called Token Issuers. The types of tokens that issued by the OAuth profile are Access Tokens, Refresh Tokens, ID Tokens as well as one-time-use (nonce) type tokens. Token Issuers are powerful entities in the Curity Identity Server, and more on how they can be used is documented in a the section on Token Issuance.
The OAuth profile relies on the authentication of users as well as clients. Depending on which OAuth flows are used, authentication is done differently.
By default, client authentication is done using client-secrets. See the section on Client Authentication to find out more. User authentication can be achieved by enabling an Authentication Service Profile and pointing the OAuth Profile to this Authentication Service Profile. This is described in the Configuring OAuth User Authentication section.
Note
When OAuth’s code-flow as well as OAuth’s Resource Owner Password Credentials (ropc) flow are supported, the OAuth profile should configure the same Credential Manager with both the Authentication Service profile as well as the OAuth profile.
Other parts that must be managed within an OAuth profile, are scopes and claims as well as clients.
OpenID Connect¶
An OAuth profile can be configured to support OpenID Connect. This means that the OAuth functionality is profiles to conform to the standardized OpenID Connect specification. What this means and how to configure this, can be found in the section on OpenID Connect.
Pre-requisite configuration¶
- Token Issuers
- Credential Managers
Base Configuration of an OAuth Profile¶
Important
The profile is located in the configuration at: /profiles/profile{id as:oauth-service}/settings/authorization-server
This section mentions a limited set of configuration options that are required to configure a basic OAuth Profile as part o the Curity Token Service.
-
'oauth-profile' -
authentication-service/authentication-profile(string, mandatory) A reference to the Authentication Profile that is used for user authentication. Relates to the client configuration, that configures a set of properties that are used when authenticating users.
-
client-capabilities/grant-types, client-capabilities Configure the capabilities (i.e. grant types, OAuth-flows, etc) that are available to clients from the Token profile. These include
code,implicit,resource-owner-password-credentialsandclient-credentials, as well asintrospection,token-exchange,assisted-tokenanddevice-authorization.
-
scopes¶ Configure the scopes that are supported by the Token Service profile
-
openid-connect Configure whether or how the Token Service supports OpenID Connect
-
client-store Configure the clients for the Token Service profile
-
default-token-issuer Configure the default token issuer properties. Custom token issuers can be configured on top of the default token issuers.
-
account-manager An (optional) reference to a configured account manager. This is used for looking up user data, such as that presented by the userinfo endpoint or in ID tokens (when OpenID Connect is configured).
-
Example create request¶
<profile>
<id>oauth</id>
<type xmlns:as="https://curity.se/ns/conf/profile/oauth">as:oauth-service</type>
<settings>
<authorization-server xmlns="https://curity.se/ns/conf/profile/oauth">
<authentication-service>
<authentication-profile>authentication</authentication-profile>
</authentication-service>
<client-capabilities>
<code/>
<implicit/>
<resource-owner-password-credentials/>
<client-credentials/>
<token-exchange/>
<oauth-token-exchange/>
<introspection/>
<assisted-token/>
</client-capabilities>
<scopes>
<min-access-token-lifetime>8</min-access-token-lifetime>
<scope>
<id>read</id>
<description>Read scope</description>
</scope>
<scope>
<id>write</id>
<description>Write scope</description>
</scope>
</scopes>
<client-store>
<config-backed>
<client>
<id>client-one</id>
<secret>$5$E6.uk/.GKRRABFX5$UR.9doqY1vHmcH7w4H7bA/C50T2SNJmXCrC27ANVco1</secret>
<redirect-uris>https://client-one.example.com/cb1</redirect-uris>
<redirect-uris>https://client-one.example.com/cb2</redirect-uris>
<audience>client-one</audience>
<audience>rs-two</audience>
<scope>read</scope>
<scope>write</scope>
<user-authentication>
<context-info>Client One</context-info>
<allowed-authenticators>htmlScimUsers</allowed-authenticators>
<force-authn>false</force-authn>
<freshness>300</freshness>
</user-authentication>
<capabilities>
<code/>
<implicit/>
</capabilities>
</client>
<client>
<id>rs-two</id>
<secret>$5$99pw96NB5.O.tye0$1A4uyUnx36l1pyLAvDKlk0GlLxjSHBW31pt3iPxeD.D</secret>
<redirect-uris>https://rs-two.example.com/cb1</redirect-uris>
<audience>rs-two</audience>
<scope>read</scope>
<user-authentication>
<allowed-authenticators>ping1</allowed-authenticators>
<allowed-authenticators>htmlScimEmployees</allowed-authenticators>
<context-info>Resource Server Two</context-info>
<force-authn>true</force-authn>
</user-authentication>
<capabilities>
<code/>
<implicit/>
<introspection/>
<resource-owner-password-credentials/>
</capabilities>
</client>
</config-backed>
</client-store>
</authorization-server>
</settings>
<endpoints>
<endpoint>
<id>authorize</id>
<uri>/oauth/v2/authorize</uri>
<endpoint-kind>oauth-authorize</endpoint-kind>
</endpoint>
<endpoint>
<id>token</id>
<uri>/oauth/v2/token</uri>
<endpoint-kind>oauth-token</endpoint-kind>
</endpoint>
<endpoint>
<id>introspection</id>
<uri>/oauth/v2/introspection</uri>
<endpoint-kind>oauth-introspect</endpoint-kind>
</endpoint>
<endpoint>
<id>introspection-jwt</id>
<uri>/oauth/v2/introspection.jwt</uri>
<endpoint-kind>oauth-introspect</endpoint-kind>
</endpoint>
<endpoint>
<id>revoke</id>
<uri>/oauth/v2/revoke</uri>
</endpoint>
<endpoint>
<id>assisted-token-dev</id>
<uri>/oauth/v2/assisted-token</uri>
<endpoint-kind>oauth-assisted-token</endpoint-kind>
</endpoint>
<endpoint>
<id>oauth-anonymous</id>
<uri>/oauth/v2/anonymous</uri>
<endpoint-kind>oauth-anonymous</endpoint-kind>
</endpoint>
</endpoints>
<token-issuers>
<custom-token-issuer>
<id>jwtAccessTokenIssuer</id>
<issuer-type>jwt</issuer-type>
<purpose-type>access_token</purpose-type>
<data-sources>
<delegations-data-source-id>DefaultHSQLDB</delegations-data-source-id>
<tokens-data-source-id>DefaultHSQLDB</tokens-data-source-id>
</data-sources>
<jwt>
<signing-key-id>default-signing-key</signing-key-id>
<algorithm>RS256</algorithm>
</jwt>
</custom-token-issuer>
<default-token-issuer>
<jwt-issuer-settings>
<signing-key-id>default-signing-key</signing-key-id>
<verification-keystore-id>default-signature-verification-key</verification-keystore-id>
<algorithm>RS256</algorithm>
</jwt-issuer-settings>
<default-data-source>DefaultHSQLDB</default-data-source>
</default-token-issuer>
</token-issuers>
</profile>