OAuth 2.0 is an authorization framework that enables an application or service to obtain limited access to a protected HTTP resource.
OAuth is used to secure access to services that are exposed by Oracle Cloud. This is done by providing access tokens to clients with the (sometimes implicit) approval of the owner of the resource.
Oracle Cloud uses the open standard OAuth 2.0 to integrate services. Oracle Cloud doesn’t provide all the features of this standard.
The OAuth token service provided by the Oracle Cloud identity infrastructure provides secure access to the Representational State Transfer (REST) endpoints of cloud services by other cloud services and user applications.
OAuth 2.0 provides the following benefits:
It increases security by eliminating the use of passwords in service-to-service REST interactions.
It reduces the lifecycle costs by centralizing trust management between clients and servers. OAuth reduces the number of configuration steps to secure service-to-service communication.
The OAuth 2.0 implementation in Oracle Cloud has the following limitations:
It supports only two-legged OAuth, which means that no user is present to give consent. Instead, clients hold onto credentials from the user.
It supports only the user client, resource owner, and assertions workflow.
Because of the lack of three-legged OAuth, clients using the resource owner credentials workflow can’t leverage browser-based SSO protocols. Instead, clients route a user’s credentials to the OAuth token service URL to obtain an access token on behalf of the user.
Obtaining tokens from third-party OAuth token services isn’t supported.
OAuth Client Definitions
The OAuth client is the application requesting access to the resources stored on the resource server.
A client application uses OAuth to access a protected resource on behalf of a user (typically, the resource owner).
A client identifier is a unique string representing the registration information provided by the client application. Before a client application can request access to resources on a resource server, the client application must first register with the OAuth token service associated with the resource server. The registration is typically a one-time task. After the client application is registered, the registration remains valid, unless the client application registration is revoked.
Clients in possession of a client password may use the HTTP basic authentication scheme to authenticate with the authorization server. During client registration, the client application is assigned a client ID and a client password by the authorization server. The client ID and password are unique to the client application on that authorization server. If a client application registers with multiple authorization servers, each authorization server provides a unique client ID and password to the client application.
Client Redirect URI
After the client application is authorized successfully, the client application is redirected to the redirect uniform resource identifier (URI). During client registration, the client also registers a redirect URI. This redirect URI is used when a resource owner grants authorization to the client application. When a resource owner has successfully authorized the client application using the OAuth token service, the resource owner is redirected back to the client application, using the redirect URI.
Supported OAuth Workflows
The OAuth authorization workflow includes two different usage scenarios, two-legged OAuth workflow and three-legged OAuth workflow.
Oracle Cloud supports only the two-legged OAuth workflow.
The two-legged OAuth workflow includes a client and a resource server. In OAuth two-legged authorization, consent from the resource owner is either assumed or not required. An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. The authorization grant is given to a client application by the resource owner, in cooperation with the OAuth token service associated with the resource server.
Resource owner password credentials grant: The resource owner’s password credentials (that is a user name and password) can be used directly as an authorization grant to obtain an access token.
Client credentials grant: The client credentials (or other forms of client authentication) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client application, or to protected resources registered with the authorization server. Client credentials are used as an authorization grant typically when the client application is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization registered with the authorization server.
User assertion grant: A user assertion is a user token that contains identity and security information about the user. A user assertion can be used as an authorization grant to authenticate the user. This user token can be used instead of a user name and password.
Working of Two-Legged OAuth Flow
The authorization server returns a request token to the OAuth client, which the client then uses to request an access token. Because the request token is preauthorized, the authorization server's token service returns an access token to the client. In the case of the two-legged OAuth workflow, the OAuth client becomes the resource owner. In OAuth two-legged authorization, the OAuth Client is preapproved to access resources. This arrangement fits a service-to-service model, especially, when the requesting service and the resource server are in a close partnership and the resource owner’s approval is either assumed or not required.