oauth2 and openID Connect
Overview of each
OAuth2
It is about authorization (e.g granting access to resource), it operates on tokens and allows for third parties to access resources which belong to another user (of course he agreed beforehand). User in this case is called “Resource owner”. Tokens which are issued usually can be invalidated at any time, they also contain list of scopes (actions) which can be performed by entity using token. For oauth2 to work you need to create set of credentials (which are called client or application) which are usually called client_secret
and client_id
or similarly, those credentials are used by oauth2 provider to distinguish between different third parties. You can see example of this functionality when you click login with facebook/google/etc.
It can be simplified to:
- User goes to third party page and clicks login with facebook
- New window appears, it is directly taken from facebook servers, facebook recognizes which third party is trying to gain access for user because
client_id
was sent. - Users logins and authorizers third party page to access his/her resources
- Windows closes and third party page now have access token which allows to make calls to facebook on behalf of user
There are 4 grant flows of obtaining token
Client credentials
- applications uses its own
client_secret
andclient_id
to obtain token
Usually used when there is no need for user scoped tokens, like for public resources, or resources which are directly associated with application
Resource owner
- user opens application
- user provides credentials(username/password) directly in third party application
- application sends those credentials to oauth2 server and obtains token
Not recommended should be used only in application that are fully trusted by user.
Authorization code grant
- user opens application
- application redirects user to oauth2 server login page
- oauth2 server redirects user back to original application with authorization code in url fragment
- application makes request to oauth2 server with authorization code along with its credentials (
client_secret
/client_id
) - oauth2 server validates that code belongs to given application credentials and returns access token
Most recommended type, usually safest for user and application. Requires more work than the rest of flows.
Implicit grant
- user opens application
- application redirects user to oauth2 server login page
- user enters credentials and logins
- oauth2 server redirects user back to original application with access token in url fragment
Can be used by public clients, simple to implement, usually not recommended.
openID connect
Is about identity; in oauth2 we were speaking about “what I can do”, in openID Connect we are talking about “who am I”. Those identities are provided by identity provider, and are not only related to humans, objects and services also can have ones.
OpenID Connect gives you token (e.g jwt) but this time this token authenticates person, instead of list of allowed actions(scopes) like in oauth2.