OAuth2 security

I have been getting multiple calls/emails related to leveraging OAuth2 security feature within Oracle Fusion Middleware so decided to write a blog on it. This blog provides an overview on OAuth2.0

Here is the definition from OAuth2.0 spec.

"The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf."

In simpler terms

"OAuth2 enables applications to access each others data without sharing passwords"

OAuth2 uses the concept of delegated authentication and Access token (typically JWT token) to achieve this. Many services such as Facebook, Github, Twitter and Google already provides Oauth2 implementations. Here is a list from Wikipedia. Let me explain this with a simple use case.

Use case: You want to print your photos posted on Facebook. There is a photo printing app (third party / client app) which provides this service.

• You want to ensure that the printing application only gets access to your photos but not to other operations like posting on your wall, access to your friend and there photos. 
• You don't want to share your Facebook password with client app. 
• You don't want to sign up with the client app.
• You want to ensure that the printing app gets access to your resources for a limited time period and after that you wan't to revoke its access.

Let's see how its implemented using OAuth2. The client app (printing app) which intends to access user resources provides an option on there home page to login via Authorization Server. In this scenario Facebook server acts as the Authorization server

Once you click on "Login with Facebook" you are redirected to authenticate with your facebook credentials.

After login you are presented with an authorization window asking for your permission whether to allow the app or not to access your information and act on your behalf. You choose what all information the client app can access.

Once you click okay you are redirected back to the app. Once the app is authorized it can get an access token from Facebook which can be used to access your resources. In this case the app do not handles authentication but delegates it to Facebook (authorization server). From client app perspective they can get access to user's resources and from user's perspective they get a smoother experience.Users are saved from creating login with every new app and the pain of creating password and remembering them. Also if at a later point of time you wish to revoke access of client app you can do this by logging into Facebook/Authorization server and remove the access of app.
Now let's try to map the above example with OAuth2.0 flow defined in spec.

OAuth2.0 defines four roles:
1) Resource Owner - the User user who authorizes an application to access their account. The application's access to the user's account is limited to the "scope" of the authorization granted
2) Client - the application that wants to access the user's account.
3) Resource Server - hosts the protected user accounts
4) Authorization Server - verifies the identity of the user then issues access tokens to the application. Can be same as Resource server, as in above example

A - The application (client) requests authorization to access service resources from the user (Resource Owner)
B - If the user authorized the request, the application receives an authorization grant
C - The application (client) requests an access token from the authorization server (API) by presenting authentication of its own identity, and the authorization grant
D - If the application identity is authenticated and the authorization grant is valid, the authorization server issues an access token to the application. Authorization is complete.
E - The application requests the resource from the resource server (API) and presents the access token for authentication
F - If the access token is valid, the resource server (API) serves the resource to the application

This is the most common OAuth2 flow: the authorization code flow or 3-legged flow. OAuth2 provides other flows which work for slightly different scenarios

• Authorization Code: used with server-side Applications
• Implicit: used with Mobile Apps or Web Applications (applications that run on the user's device)
• Resource Owner Password Credentials: used with trusted Applications, such as those owned by the service itself
• Client Credentials: used with Applications API access, this grant type is used when the app is also the resource owner. An end user does not participate in this grant type flow. 

That's all for now, in my next blogs i will explain How to use Oracle OAuth2 support (provided in 11gPS6MLR and PS7) release to secure your apps and how its different from other SSO solution like SAML, OpenID