Token Profile Configuration#
The OAuth profile consists of multiple components which are described in more detail in their own sections:
-
Configuring OAuth User Authentication
- OAuth Clients
- Scopes and Claims
- OpenID Connect
- Issuing OAuth and OpenID Connect Tokens
- Redirect URI Validation Policies
- Event Handling
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
- Database Client GraphQL API endpoint
- Device Flow endpoint
See the Developer guide about how to use these.
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 Token Issuers .
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 OAuth Clients Configuration 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 Base Configuration of an OAuth Profile section.
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 OpenID Connect Configuration .
Pre-requisite configuration#
- Token Issuers
- Credential Managers
Base Configuration of an OAuth Profile#
The profile is located in the configuration at: /profiles/profile/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.
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-credentials and client-credentials, as well as introspection, token-exchange, assisted-token and device-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>