This page describes Ubisecure SSO support for the OAuth 2.0 authorization framework.
OAuth 2.0 messages involve credentials and access tokens that allow the bearer to retrieve protected resources. Use Transport Layer Security (TLS) to protect sensitive messages.
About OAuth 2.0 Support
OAuth 2.0 Authorization Framework (IETF, RFC 6749) enables a resource owner to grant a client application access to the owner's service.
Ubisecure SSO can function as an OAuth 2.0 Authorization Server. In this role, Ubisecure SSO authenticates resource owners and obtains their authorization in order to return access tokens to clients.
When using SSO as an OAuth 2.0 Authorization Server, you can register clients in the Ubisecure SSO Management Interface
OAuth 2.0 Authorization in WebSSO Use cases
Ubisecure SSO can function as an OAuth 2.0 Authorization Server to provide a WebSSO user experience for users accessing e-services using a Web browser. In such setups, the browser acts as the OAuth 2.0 Client.
| Figure 1. Basic OAuth 2.0 WebSSO Use case entities and setup |
The sequence diagram of the OAuth 2.0 Authorization in WebSSO Use cases is described in the page OAuth 2.0 API - SSO, - Authorization code grant and Web Single Sign-On.
OAuth 2.0 Authorization in Mobile Use cases
Ubisecure SSO can function as an OAuth 2.0 Authorization Server to provide Mobile users a secure access to e-services using a native mobile application, such as Google Android Apps, iOS apps on iPhones or Windows Mobile Apps. In such setups, the native mobile application acts as the OAuth 2.0 Client.
| Figure 2. Basic OAuth 2.0 Mobile Use case entities and setup |
In a typical mobile use case example a user (resource owner) grants access to a mobile bank application (OAuth 2.0 Client) to access bank account information in the bank's e-banking server (OAuth 2.0 Resource Server).
The following flow diagram indicates the primary roles Ubisecure SSO can have in a OAuth 2.0 protocol mobile use case flow.
| Figure 3. Ubisecure mobile login process flow using OAuth 2.0 |
The exact sequence diagram of the OAuth 2.0 Authorization in Mobile Use cases is described in Authorization code grant and native applications - SSO.
OAuth 2.0 Authorization of Enterprise Account Users in API Security Use cases
Many e-services and content providers have information and data content which they want to offer their customers and partners through a secure API, to enable easy and secure consumption and aggregation of that data content into various 3rd party e-services and applications and based on contractual relationships.
| Figure 4. Accessing Data from backend API On Behalf of Authorized User using OAuth 2.0 |
In such setups, the portal or e-service of the Enterprise Account Customer acts as the OAuth 2.0 Client, whereas the content provider e-service API is the OAuth 2.0 Resource Server.
In this use case the Enterprise Account Customers are authorized based on the System Account contractually issued to them, based on the business relationship between the Content Provider and the Enterprise Customer.
Figure 5. Contractual Delivery of the Data over Secure API Using OAuth 2.0 Authorization and System Accounts |
The sequence diagram of the OAuth 2.0 Authorization of Enterprise Account Users in API Security Use cases is described in page Password grant - SSO.
OAuth 2.0 Authorization of Individual Users in API Security Use cases
In many Internet use cases, some of the data to be presented to n authorized user resides in a backend-server, often provided by a 3rd party. In these use cases data must be looked up from behind a backend API and the backend serve r and its content is accessed On Behalf of the Authorized User. This setup sometimes referred to as a three-legged OAuth 2.0 use case.
In such setups, the portal or e-service has a dual role: First, it acts as the OAuth 2.0 Resource Server for the OAuth 2.0 Client. Secondly, it also acts as a OAuth 2.0 Client whereas the backend content provider e-service API is the OAuth 2.0 Resource Server.
| Figure 6. Accessing Data from backend API On Behalf of Authorized User using OAuth 2.0 |
The sequence diagram of the OAuth 2.0 Authorization of Individual Users in API Security Use cases is described in page Password grant - SSO.
| Figure 7. Sequence diagram of authorization code grant for Authorization of Individual Users in API Security Use cases |
OAuth 2.0 Grant Types in Ubisecure SSO
OAuth 2.0 Authorization Grant
The authorization code grant starts with the client, such as a web-based service, redirecting the resource owner's user-agent to the Ubisecure SSO authorization service. After authenticating the resource owner and obtaining the resource owner's authorization, Ubisecure SSO redirects the resource owner's user-agent back to the client with an authorization code that the client uses to request the access token.
The following sequence diagram outlines a successful process from initial client redirection through to the client accessing the protected resource.
OAuth 2.0 Resource Owner Password Credential Grant
The resource owner password credentials grant lets the client use the resource owner's user name and password to get an access token directly.
This grant type should be used in a secure context where other authorization grant types are not available, such as a client that is part of a device operating system using the resource owner credentials once and thereafter using refresh tokens to continue accessing resources.
The following sequence diagram shows the successful process.
OAuth 2.0 Tokens
Authorization code lifetime is 10 minutes (the recommended setting in RFC 6749)
Access token lifetime equals SSO session lifetime
Ubisecure SSO OAuth 2.0 Endpoints
In addition to the standard authorization and token endpoints described in RFC 6749, Ubisecure SSO also exposes a token information endpoint for resource servers to get information about access tokens so they can determine how to respond to requests for protected resources.
Please refer to the page OAuth 2.0 API - SSO for more information about the endpoints.
Ubisecure SSO as OAuth 2.0 Client
Ubisecure SSO includes OAuth 2.0 Client functionalities implemented as authentication methods in the product.
When Ubisecure SSO acts as an OAuth 2.0 Client, it provides an SSO session after successfully authenticating the resource owner and obtaining authorization. It is just like any other authentication module, one that relies on an OAuth 2.0 authorization server to authenticate the resource owner and obtain authorization.
The configuration of Ubisecure SSO to act as OAuth 2.0 Client is described here and on the page OAuth 2.0 authentication method - SSO.
Register OAuth 2.0 Clients
An OAuth 2.0 Client is registered with the Ubisecure SSO OAuth 2.0 Authorization Service by creating and configuring an OAuth 2.0 Agent in the Ubisecure SSO Management Interface. The steps to perform this task are described here.