I have seen many people using above tools on developments. But without having clear idea about the concepts and boundaries. This is all about authorization and authentication. So let’s dig in to those one by one see what is best. Also this article include sample code from java to use OAuth with facebook.
OAuth is an open standard for authorization. OAuth provides a method for clients to access server resources on behalf of a resource owner. It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials, using user-agent redirections.
OAuth is a service that is complementary to, and therefore distinct from, OpenID. OAuth is also distinct from OATH, which is reference architecture for authentication
OAuth born from the concept of Blaine Cook’s twitter open ID implementation in 2006.The OAuth discussion group was created in April 2007 and On October 3, 2007, the OAuth Core 1.0 final draft was released.
OAuth 2.0 is not backward compatibility with OAuth 1.0. its more focus on simplicity of client development
Facebook graph API and Google support for OAuth 2.0 and Microsoft added OAuth 2.0 to their API in 2011. Finally OAuth 2.0 Framework and Bearer Token Usage were published in October 2012
Earlier day’s application limited to either standalone or intranet. In that case domain based security control has been introduced. Also its served the purpose. But when business requirement and business spread all over the locations people wanted to have single sign on over the application as well as intranet integrations. Means interconnected intranets
SOAP, XML, WS* were introduced to meet the new security requirements. However technology paradigm shit took place and mobile platform introduced. Now they don’t have SOAP or WS or another enterprise level stack as those are end use consumer devices. Based on easy and attractive design they took over market in very short period. Therefore enterprise application had to blend or invent technologies to take new mobile platform onboard. Therefore new technology introduced based on the http and json and few limited protocols as those are the only protocol which mobile device recognized.
During this revolution many companies has developed many services as well as applications. There are many fake or insecure applications and services also released. As a result people felt fear to give their username password for the all applications as that can lead for the security breach. Instead of that people wanted to have single authentication server and once user authenticate from server all applications are supposed to use that authentication for their applications. Also its help to maintain security and passwords.
OAuth2 and OpenId
Before understand those two you need to understand the principle of authentication and authorization. Authentication verifies who you are. Authorization verifies what you are authorized to do. Authentication mechanism can be varying from simple as a password, public key authentication, or as complicated as Kerberos based system. After it authenticated system verify user has access resource called ABC? or Is user authorized to perform operation XYZ? And so on. Simply Authorization refers to rules that determine who is allowed to do what while Authentication is the process of ascertaining that somebody really is who he/she claims to be.
Originally openid designed for authentication and OAuth designed for authorization. Later on openid released as openid Connect as unification of the two and serves for both. but does not change their original functionalities
Consider following scenario.
Just hypothetically imagine krishantha.net site is powered with OAuth or OpenId
In OpenId [authentication]
- You want to access your account on krishantha.net
- Krishantha.net is asking your openId
- You entered your username for openId
- Krishantha.net will redirect you to the your openid providers site
- User give password to openId provider and authenticate him self
- openId provider will redirect user back to krishantha.net site
- krishantha.net will grant you to access your account
in OAuth [authorization]
- You are in krishantha.net account and you need to access your images from creativeshuttersphotography.com site.
- Krishantha.net site will redirect you to creativeshuttersphotography.com site
- You enter you credebtial to creativeshuttersphotography.com siteand authenticated your self. This is like in openId
- creativeshuttersphotography.com site will ask you want to give permition to access photos of creativeshuttersphotography.com site
- you select yes
- creativeshuttersphotography.com site will redirect back to krishantha.net site
- krishantha.net can access creativeshuttersphotography.com site
Hope you have understood the concept behind those two concepts
JWT – Jason Web Token
JSON Web Token (JWT) is a means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS) and/or encrypted using JSON Web Encryption (JWE).
Security token is essential object in enterprise application security. More or less it contains following information
- subject (Claims)
- sign (temper proof authenticity)
- expiration information
Client requesting token and provider issue token also here were various token systems in history as well as today
- SAML (Xml based)
- SWT (Simple Web token) – URL encoded system only symmetric supported
- JSON Encoded
- Support for symmetric and asymmetric signatures
- Support for symmetric and asymmetric encryption
Symmetric vs Asymmetric
Now I know you have problem what symmetric and what Asymmetric. Let me to explain in very breaf
- Let imagine A need to send confidential message to B
- A use a key and encrypt the message (convert plain text to cipher )
- B get the cipher message and he know the key as well
- So B can decrypt the message and read
- This is use two keys call public and private
- A get B’s public key and encrypt
- B and only B has private key for the corresponding pubic key
- So he can decrypt the message
- This can solve the problem of key distribution for symmetric.
JWT has two major parts
- Meta Data
- Algorithm and key information
- Issuer (iss)
- Audience (aud)
- IssuedAt (iat)
- Subject (sub)
- Expiration (exp)
Its need to have signature as well. Then encode all three separately in base 64 encode and send to server
What is OAuth 2
OAuth 2.0 is the next evolution of the OAuth protocol which was originally created in late 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification is being developed within the IETF OAuth WG and is based on the OAuth WRAP proposal.
OAuth spec has confused key words as “client” and “Resource owner” to understand this concept just imagine that you have google account. Now you are going to allow krishantha.net site to access your contacts. In this case client is krishantha.net site and resource owner is you!!!! As those addresses are own by you.
Whole idea of this is give limited access to your resources without giving you password. For example just think when you are in hotel room you have access card. Which can use to open safety drawers, refrigerator , and other get telephone calls , access intenet and so on. So when you leave your room you may give that access card to room service by trusting the person as he is in staff. However it is possible him to access your resources as he is granted access with access card. To overcome this issue they do have room service card which has only limited access to the resources in the room. OAuth is about concept to give room service card to your data.
There are 4 parties involve to solve this problem
- Resource owner
- Authorization server
When client (software) need to access you ask them to use authorization server. Then you enter your username and password of that server on their interface. Then it will validate you and give access token to client. Now client can use that token to access the resources it wants.
In practical implementation resource and authorization server in trusted zone as they are in same party implementation. For example for your google contact google has authorization server. For your facebook photos facebook authorization server. In that case it tightly couples relationship. Also resource owner trust resource server. That’s why he use it J . as a result resource owner trust authorization server.
OAuth 2 flows
There are 4 type of flows for OAuth2
- Authorization Code for apps running on a web server
- Implicit for browser-based or mobile apps
- Password for logging in with a username and password
- Client credentials for application access
Authorization Code for apps running on a web server
This is the most common type of application you have when dealing with OAuth servers. Web apps are run on a server where the source code of the application is not available to the public. When you want to give access to your some resources without giving password for the site what you are browsing now, you can use this. This case your site will REDIRECT you to particular authorization server. If webserver making multiple request it can use STATE parameter for map callback response with request
You can give a link to authorization server like
And it will prompt a dialog box to user. After he click allow its redirected back to site with code. Its initially send code to client and then client directly communicate with server with the code to get the information it wants (token). In that case those are not visible to resource owner (user agent). There is optional key send by auth server call “refresh token”. If the first access token is expired client want to request access back from resource owner to get new auth code. To prevent that it has refresh token which sent to web app and web app can use that token to request new token from auth server in the event of token expire. But in this case it become life time. So most server implemented interface user to revoke access
This type of flow needs a pre-registration with server
Implicit for browser-based or mobile apps
Browser-based apps run entirely in the browser after getting source code from a web server. Since the entire source code is available to the public, they cannot maintain the confidentiality of their client secret, so the secret is not used in this case
You can give a link to authorization server like
And it will prompt a dialog box to user. If the user clicks “Allow,” the service redirects the user back to your site with an access token. Then you need you grab that token and make API calls with the token
For mobile apps also cannot maintain the confidentiality of their client secret. Because of this, mobile apps must also use an OAuth flow that does not require a client secret. With this concept token is exposed to local operating system. So there are no refresh tokens.
Password for logging in with a username and password
OAuth 2 also provides a “password” grant type which can be used to exchange a username and password for an access token directly. This obviously requires the application to collect the user’s password. As a result users may hesitate to use this service unless this app comes from the auth service provider.
Client credentials for application access
There are scenarios that applications may wish to get statistics about the users of the app. In this case, applications need a way to get an access token for their own account, outside the context of any specific user. OAuth provides the client_credentials grant type for this purpose. This is machine to machine communication sort of concept
So far we discussed about OAuth2 authorization. But there are scenarios you need just authentication only. That means without having user module just to authenticate via external system. In authorization authentication happen behind the scene. Since that architecture defined in that way it has its own loophole.
For example get the implicit flow.
- You decide to log to the particular app using Facebook credentials.
- According to the architecture Facebook will send token directly to app
- Then app developer can write program to steal that token and use in other app to impersonate you
- There is no way to resource server to identify this as fake because authorization happen in other path
Openid Connect build on top of OAuth2 and it has following flows
- Authorization code flow
- Implicit flow
Also it comes with some new concept such as session management (how u can logout), ID token , user info endpoint
This ID token carrying this token for whom and its prevent above weakness we discussed.
OAuth2 is God?
After reading all above you may feel like all the problems are solved? Is really it is ? Eran Hammer who was the lead author of 2.0 specifications (he has resigned) made few comments when he left from OAuth2. Those are considerably true. Following article will give you good understanding and idea.
But if you kind of expert on web security or those API stuff you will realize all facts he took are not 100% true and we do have workaround for those. But those articles will help you to open your eyes on those.