Overview: Configure OAuth Client and Resource Server¶
Overview of OAuth 2.0¶
Open Authorization (OAuth) 2.0 is a framework that allows an application to obtain limited access to an HTTP service on a user’s behalf. OAuth standard introduces four different roles in a typical OAuth flow:
Resource server (RS): A server hosting the protected resource.
Resource owner (RO): An entity capable of granting access to a protected resource. This can be, or is usually, a user on a client device.
Client application: An entity making protected resource requests on behalf of the resource owner and with its authorization. Examples include email and office productivity applications.
Authorization server (AS): Issues access tokens to the client application after successfully authenticating the resource owner and obtaining authorization.
OAuth grant types¶
An authorization grant is a credential the client uses to obtain an access token. The credential represents the resource owner’s authorization to access its protected resources. OAuth 2.0 defines four different grant types.
Authorization code: This authorization is optimized for server-side applications that maintain client confidentiality (client ID/client secret). The client redirects the RO to an AS, which directs the RO back to the client with the authorization code. The RO credentials are never exposed to the client application.
Implicit: This authorization is used for mobile and web applications that cannot guarantee client confidentiality (client ID/client secret). Instead of issuing the client an authorization code, the application issues an access token directly. The redirection URI used to deliver the access token to the client verifies the client’s identity. The AS does not authenticate the client.
Resource owner (RO) password credentials: Users provide their credentials directly to the client application, which uses them to obtain an access token from the service. You should only use this authorization when the user trusts the application, such as when the service owns the client application or it’s the user’s desktop operating system.
Client credentials: The client submits credentials to the AS for an access token. The client typically uses this authorization grant when it acts on its behalf (the client is also the resource owner) or requests access to protected resources based on an authorization previously arranged with the authorization server.
Extension: This is an extension mechanism for defining new extension grant types to support additional clients or to provide a bridge between OAuth and other trust frameworks.
BIG-IP Next Access implements OAuth service for Authorization code and RO password credentials grant types.
OAuth token types¶
As an OAuth authorization server, Access supports bearer access tokens and refresh tokens. In addition, for use as bearer access tokens and refresh tokens, Access supports opaque tokens and JSON web tokens.
About access tokens
As defined in the OAuth 2.0 specification (RFC 6749), an access token is a credential used to access protected resources. An access token is a string that represents an authorization issued to the client. The resource and authorization servers enforce the scopes and durations of access.
About refresh tokens
As defined in the OAuth 2.0 specification (RFC 6749), a refresh token is a credential used to obtain an access token. When the current access token expires, the client uses a refresh token to get a new access token from the authorization server. If refresh tokens are enabled in the configuration, the OAuth authorization server issues a refresh token to the client when it issues an access token. Unlike access tokens, a refresh token is for use with authorization servers only and is never sent to a resource server.
About opaque tokens
Opaque tokens are issued in a proprietary format. Only the OAuth authorization server that issues the token can read and validate it. The OAuth authorization server stores an opaque token for its lifetime and has the ability to revoke it. Therefore, resource Servers must check the validity of the access token with an OAuth Authorization Server whenever they receive the opaque token from the OAuth clients. This increases the overall latency and response time of the APIs. In addition, it requires high processing power and server resources because the server has to manage an extensive access token database to control the token lifecycle. However, an opaque token can provide an organization with highly secure token management.
About JSON web tokens
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information in a JSON object between OAuth entities. This information can be verified and trusted because it is digitally signed. In addition, JSON tokens are not stored on an OAuth authorization server and cannot be revoked. When BIG-IP Next Access is configured to act as an OAuth client, it uses JSON web keys (JWKs) to validate the JSON web tokens it receives.
Access support for OpenID Connect¶
OpenID Connect adds an identity layer on top of OAuth 2.0. It allows clients to request and receive information about authenticated sessions and end-users. When configured as an OAuth client/resource server, Access can interact with an OpenID Connect provider to get the following:
UserInfo requests: Access can make UserInfo requests to an endpoint specified in an OAuth provider configuration. Access supports UserInfo requests from the OAuth Client item in an Access policy.
ID Token: The authorization server issues the ID Token when the client application requests one during user authentication. It contains claims about the authenticated user. The ID Token allows the client application to verify the user’s identity and get claims about them. Access obtains the ID Token from the OAuth provider when OpenID Connect is true (enabled) in the OAuth Client item.
BIG-IP Next Access as OAuth Client and Resource Server¶
You can set up BIG-IP Next Access as an OAuth Client, a Resource server, or as both Client & Resource Server.
BIG-IP Next Access as OAuth Client using Authorization code grant
The user tries to access an application protected by BIG-IP Next Access.
BIG-IP Next Access redirects the user to an Authorization Server (OAuth provider) for authentication.
The authorization server authenticates the user.
The authorization server redirects the user back to BIG-IP Next with the authorization code.
BIG-IP Next Access exchanges the authorization code for an access token and ID token from the OAuth provider if using OpenID connect.
BIG-IP Next performs the access control decision based on the retrieved user settings.
BIG-IP Next Access as Client and Resource Server using Authorization code grant
The user tries to access an application protected by BIG-IP Next Access.
BIG-IP Next Access redirects the user to an Authorization Server (OAuth provider) for authentication.
The authorization server authenticates the user.
The authorization server redirects user back to BIG-IP Next with the authorization code.
BIG-IP Next Access exchanges authorization code for an access token from the OAuth provider.
BIG-IP Next Access retrieves the user settings from the OAuth provider using the access token.
The access control decision is performed based on the retrieved user settings.
BIG-IP Next Access as OAuth Client using RO password credential grant
The user tries to access an application protected by BIG-IP Next Access.
BIG-IP Next Access collects user credentials.
BIG-IP Next Access uses the collected user credentials to retrieve an access token from the OAuth provider.
BIG-IP Next performs the access control decision based on the retrieved user settings.
BIG-IP Next Access as Client and Resource Server using RO password credential grant
The user tries to access an application protected by BIG-IP Next Access.
BIG-IP Next Access collects user credentials.
BIG-IP Next Access uses the collected user credentials to retrieve an access token from the OAuth provider.
BIG-IP Next Access retrieves the user settings from the OAuth provider (configured to support JSON web tokens) using the access token.
The access control decision is performed based on the retrieved user settings.
OAuth Requests¶
As per the specifications of the provider, you can configure the following OAuth requests:
Authentication Redirect Request: Specifies an auth-redirect-request type of request, that redirects a user to an OAuth server. You can configure this request in the OAuth client item when the OAuth Client is configured with the authorization-code grant type. The item uses this request at the start of a session.
Token Request: Specifies a token-request type of request. It accesses the authorization server to obtain an access token or exchange an authorization code for an access token. You can configure this request in the OAuth client item. The OAuth Client item uses this request at the start of a session.
Refresh Token Request: Specifies the token-refresh-request type of request. It refreshes an expired access token. Access uses this request on a per-request basis. You can configure this request in the OAuth client item.
Validate Token Request: Specifies the validation-scopes-request type of request. It accesses the authorization server to get a list of scopes associated with an access token and scope data for those scopes. Access uses this request on a per-request basis. You can configure this request in the OAuth scope item. The item uses this request at the start of a session.
Scope Data Request: Specifies the scope-data-request type of request. It accesses an authorization server to get scope data. You can configure this request in the OAuth scope item.