OAuth Services generates a Client Token, a User Token and an Access Token.
The Client Token is generated by OAuth Services when using the Client Credentials grant type without any scope for confidential clients, or for mobile clients. The User Token is generated by OAuth Services using the User Credentials grant type without any scope. The Access Token is generated with supported grant types using scope parameters. See Clients - Identity Federation and OAuth Services for details on grant types.
Note:
A user and client can provide credentials in the form of a JWT token or an assertion for verification and generation of one of the three tokens. It is possible to use a Client Token or a User Token generated by OAuth Services as a Client Assertion or a User Assertion respectively but that is not common.
The Refresh Token is also generated by OAuth Services. It is issued when an offline scope is presented in the Access Token request and usually has a higher expiration time than the Access Token. A Refresh token can be used to get an Access Token. The following sections contain additional details.
If OAuth Services determines that a user must consent to the request for access to a protected resource, a consent form is displayed. After the user consents, OAuth Services returns an authorization code to the Client service provider. The Client then sends the authorization code to the Token Endpoint and requests an OAuth Services Access Token. (When making the request, the Client authenticates with OAuth Services.) If received, the Access Token allows access to the protected resources. See Understanding the Authorization and Authentication Endpoints for details on the Token Endpoint.
Oracle Access Management can embed custom attributes in Access Tokens. Custom attributes are configured as part of the Service Profile or the Custom Resource Server. They are defined as static or dynamic.
Static Attributes - Attribute name and value pairs where the value is fixed at the time that you define the attribute. For example, name1=value1.
Dynamic Attributes - User-profile specific attributes. You must also configure the User Store setting on the Service Profile Configuration page. This setting defines the source of the User Profile attributes. The User Profile Service (and/or the underlying IDS interface) may be used to retrieve attribute names and values. Because dynamic attributes are user related, the user consent page (if configured) shows that the configured attributes are being shared with clients and resources.
Configuring Service Profiles and Configuring Service Profiles contain more information. Keep the following guidelines in mind when configuring custom attributes:
Do not use the same name for a static and dynamic attribute.
Avoid using the same name when adding custom attributes to the service profile configuration and the scope configuration. If you define the same attribute name in both locations, the scope-based attribute value takes precedence.
Custom attributes appear as claims in access tokens. JWT-based access tokens contain standard JWT claims along with OAuth Services specific ones. For example:
Standard
"exp":1357596398000, "iat":1357589198000, "aud":"oam_server1", "iss":"OAuthServiceProfile", "prn":null, "jti":"340c8324-e49f-43cb-ba95-837eb419e068",
OAuth Services Specific
"oracle.oauth.user_origin_id":"john101", "oracle.oauth.user_origin_id_type":"LDAP_UID", "oracle:idm:claims:client:macaddress":"1C:AB:A7:A5:F0:DC", "oracle.oauth.scope":"brokerage", "oracle.oauth.client_origin_id":"oauthssoapp1id", "oracle.oauth.grant_type":"oracle-idm:/oauth/grant-type/resource-access-token/jwt"
These claims are available as part of the access token generated by OAuth Services. Because the custom attributes appear as claims in a JWT-based access token, the following naming restrictions apply:
Avoid JWT standard claim names.
Avoid names with an "Oracle" prefix (as shown above)
OAuth Services can be configured to allow the Client to use a refresh token to obtain additional access tokens with identical or narrower scope.
The refresh token is used when the access token is no longer valid. The purpose of a refresh token is to improve security. Access tokens are short-lived, so if stolen, they are only useful for a limited period. Refresh tokens are longer-lived, but are less frequently sent to the server, thus reducing the likelihood that they will be stolen.
Any scope can request and use a refresh token, however, the refresh token is typically used when the user is offline. When configuring a Resource Server, the administrator can designate one scope to be the offline scope. If an access token request includes the scope designated as the offline scope, the server will include the refresh token with the access token. If the offline scope field is not configured, the server will not issue a refresh token. See Custom Resource Servers Configuration Page for details.
The client must be configured to use the refresh token. See Service Profile Configuration Page and Web Clients Configuration Page for information about refresh token settings.
Mobile applications must register with Oracle Access Management prior to using OAuth Services and each registration is specific to one app on the device.
After the application registration, the mobile app will have a Client Token. It uses this token as the security credential for making Access Token requests. See Understanding Mobile OAuth Services Server-Side Single Sign-on for details.