Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
OAuth2 Presentaion
1.
2. What is OAuth ?
Oauth is the industry-standard protocol for authorization.
Oauth is an specification/Protocol that enables
applications to obtain limited access to user accounts.
How it works ?
It works by delegating user authentication to the service
that hosts the user account, and authorizing third-party
applications to access the user account.
Who will use?
It provides authorization flows for web and desktop
applications, and mobile devices.
3. • Authorization Server
e.g. Face book, Google, Git hub etc.
https://en.wikipedia.org/wiki/List_of_OAuth_providers
• Resource Server
Limited User information
•Client (Third party App)
Application which requires authentication and authorization
• Resource Owner
User who has account in Authorization server
6. Access Tokens (Short lived)
With this token, we access the authorized resource
Refresh Tokens (Long lived)
When ever access token expires, we use refresh token to get
the new access token.
7. An authorization code is an intermediate token used in the server-
side app flow. An authorization code is returned to the client after
the authorization step, and then the client exchanges it for an
access token.
Scope is a way to limit an app’s access to a user’s data. Rather
than granting complete access to a user’s account, it is often useful
to give apps a way to request a more limited scope of what they
are allowed to do on behalf of a user.
e.g. read, write, trust or email etc..
8. Authorization End Point
https://authorization-server.com/authorize
Returns the response with authorization code and state
And also gives the screen to user saying Approve /Deny of sharingyour
public data with Client Application.
Token End point
https://authorization-server.com/token
{
"access_token": "381e44d1-3b79-4b2b-826e-b414f06989b8",
"token_type": "bearer",
"refresh_token": "3bb99a06-5d9b-4329-91df-42ad0b952853",
"expires_in": 43199,
"scope": "read write“
}
9. The OAuth 2.0 specification lists four different types of
authorization grants. Each type has different security
characteristics.
19. • Decouples resource owner credentials
over head from Resources.
• Client Application doesn’t have to
maintain authentication.
• Resource Owners (Users) don’t need to
have multiple logins.
Authorization Server – Facebook or Google or Github etc..
Resource Server – User Accounts
Client – Redbus.in
Resource Owner – Users who has account in Facebook/Google/Github and wants to log in Redbus.in application
Google Oauth
https://accounts.google.com/signin/oauth/oauthchooseaccount?client_id=231171689615-idianhahjhk2s9rdlr1hrd9e2a09b3cj.apps.googleusercontent.com&as=-30c12e6fde8576ce&destination=https%3A%2F%2Fwww.redbus.in&approval_state=!ChRZb2hNenR2NmNUQmlSTk1hWUk4LRIfUTZNWWJUTzVhSEVhVU9xWmlfQjdtUjlrRUpzS0NoWQ%E2%88%99ACThZt4AAAAAWkceu1dXTeKbHkXCN-vEyg0EN4omYuT6&xsrfsig=AHgIfE-8qupE90XAlxCML8F4cCK8SD0-2w&flowName=GeneralOAuthFlow
Facebook O Auth Link
https://www.facebook.com/dialog/oauth?app_id=377581119008028&channel_url=https%3A%2F%2Fstaticxx.facebook.com%2Fconnect%2Fxd_arbiter%2Fr%2FlY4eZXm_YWu.js%3Fversion%3D42%23cb%3Df412aaa45d5424%26domain%3Dwww.redbus.in%26origin%3Dhttps%253A%252F%252Fwww.redbus.in%252Ff3f1486533c3e04%26relation%3Dopener&client_id=377581119008028&display=popup&domain=www.redbus.in&e2e=%7B%7D&locale=en_US&origin=1&redirect_uri=https%3A%2F%2Fstaticxx.facebook.com%2Fconnect%2Fxd_arbiter%2Fr%2FlY4eZXm_YWu.js%3Fversion%3D42%23cb%3Df3d20b7232ee724%26domain%3Dwww.redbus.in%26origin%3Dhttps%253A%252F%252Fwww.redbus.in%252Ff3f1486533c3e04%26relation%3Dopener%26frame%3Df4fa8c18f35e9c&response_type=token%2Csigned_request&scope=email&sdk=joey
DigitalOcean OAuthLink
https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read
https://developer.github.com/apps/building-oauth-apps/authorization-options-for-oauth-apps/#non-web-application-flow
More about Scope…
Some apps only use OAuth in order to identify the user, so they only need access to a user ID and basic profile information. Other apps may need to know more sensitive information such as the user’s birthday, or they may need the ability to post content on behalf of the user, or modify profile data. Users will be more willing to authorize an application if they know exactly what the application can and cannot do with their account. Scope is a way to control access and help the user identify the permissions they are granting to the application.
If you give Bearer ( Default on most implementation), an access_token is generated and sent back to you. Bearer can be simply understood as "give access to the bearer of this token." One valid token and no question asked.
On the other hand if you choose Mac and sign_type(default hmac-sha-1 on most implementation),
the access token is generated and kept as secret in Key Manager as a attribute, and an encrypted secret is sent back as access_token
JWT – JSON Web Token.
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
Authorization Code Grant
When it should be used?
It should be used as soon as the client is a web server. It allows you to obtain a long-lived access token since it can be renewed with a refresh token (if the authorization server enables it).
Example:
Resource Owner: you
Resource Server: a Google server
Client: any website
Authorization Server: a Google server
Scenario:
A website wants to obtain information about your Google profile.
You are redirected by the client (the website) to the authorization server (Google).
If you authorize access, the authorization server sends an authorization code to the client (the website) in the callback response.
Then, this code is exchanged against an access token between the client and the authorization server.
The website is now able to use this access token to query the resource server (Google again) and retrieve your profile data.
You never see the access token, it will be stored by the website (in session for example). Google also sends other information with the access token, such as the token lifetime and eventually a refresh token.
This is the ideal scenario and the safer one because the access token is not passed on the client side (web browser in our example).
t is typically used when the client is running in a browser using a scripting language such as Javascript. This grant type does not allow the issuance of a refresh token.
Example:
Resource Owner: you
Resource Server: a Facebook server
Client: a website using AngularJS for example
Authorization Server: a Facebook server
Scenario:
The client (AngularJS) wants to obtain information about your Facebook profile.
You are redirected by the browser to the authorization server (Facebook).
If you authorize access, the authorization server redirects you to the website with the access token in the URI fragment (not sent to the web server).
Example of callback:
http://example.com/oauthcallback#access_token=MzJmNDc3M2VjMmQzN.
This access token can now be retrieved and used by the client (AngularJS) to query the resource server (Facebook). Example of query: https://graph.facebook.com/me?access_token=MzJmNDc3M2VjMmQzN.
Access-Control-Allow-Origin
Maybe you wonder how the client can make a call to the Facebook API with Javascript without being blocked because of the Same Origin Policy?
his cross-domain request is possible because Facebook authorizes it thanks to a header called Access-Control-Allow-Origin present in the response.
Java Script Applications
Mobile Apps
POST https://api.authorization-server.com/token grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID
A common use for this grant type is to enable password logins for your service’s own apps.
The response will include an access token in the same format as the other grant types
When it should be used?
With this type of authorization, the credentials (and thus the password) are sent to the client and then to the authorization server. It is therefore imperative that there is absolute trust between these two entities. It is mainly used when the client has been developed by the same authority as the authorization server. For example, we could imagine a website named example.com seeking access to protected resources of its own subdomain api.example.com. The user would not be surprised to type his login/password on the site example.com since his account was created on it.
Example:
Resource Owner: you having an account on acme.com website of the Acme company
Resource Server: Acme company exposing its API at api.acme.com
Client: acme.com website from Acme company
Authorization Server: an Acme server
Scenario:
Acme company, doing things well, thought to make available a RESTful API to third-party applications.
This company thinks it would be convenient to use its own API to avoid reinventing the wheel.
Company needs an access token to call the methods of its own API.
For this, company asks you to enter your login credentials via a standard HTML form as you normally would.
The server-side application (website acme.com) will exchange your credentials against an access token from the authorization server (if your credentials are valid, of course).
This application can now use the access token to query its own resource server (api.acme.com).
The Client Credentials grant is used when applications request an access token to access their own resources, not on behalf of a user.
http://www.mysmartprice.com/
When it should be used?
This type of authorization is used when the client is himself the resource owner. There is no authorization to obtain from the end-user.
Example:
Resource Owner: any website
Resource Server: Google Cloud Storage
Client: the resource owner
Authorization Server: a Google server
Scenario:
A website stores its files of any kind on Google Cloud Storage.
The website must go through the Google API to retrieve or modify files and must authenticate with the authorization server.
Once authenticated, the website obtains an access token that can now be used for querying the resource server (Google Cloud Storage).
Here, the end-user does not have to give its authorization for accessing the resource server.
