Wednesday, December 30, 2020

OAUTH - What is OAUTH ?

What is OAUTH ?

OpenAuthorization 

Used for Authorization not Authentication.

Delegated Authorization.

Its a framework - open standard.

-----------------------------------------------------------------------------

https://d33wubrfki0l68.cloudfront.net/ecfd750086b8ac97fe5aaa08fdde917732b13225/f58f5/assets-jekyll/blog/oauth/biketoworkday-fb-login-f00e39aabbf3e44bc3570333643cbf5d966fc27367dbffd2623ff4a3694831c3.png

https://www.youtube.com/watch?v=t4-416mg6iU

https://www.youtube.com/watch?v=3pZ3Nh8tgTE

https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth

https://www.okta.com/identity-101/saml-vs-oauth/      - Do check video hosted here

https://www.varonis.com/blog/what-is-oauth/

https://www.csoonline.com/article/3216404/what-is-oauth-how-the-open-authorization-framework-works.html

https://www.geeksforgeeks.org/what-is-oauth-open-authorization/

https://www.youtube.com/watch?v=CWiwpvpCrro

-----------------------------------------------------------------------------

::Terminologies :: 

Following are the actors ->

Resource   -> A Protected Resource

Resource Owner -> Me/Myself

Resource Server -> "Service2" - Service Hosting resources - Google Drive

Client -> "Service1" - e.g. "Photo Printing Service"

-----------------------------------------------------------------------------

Examples

1) Valet Keys

2) Photo Printing Service

-----------------------------------------------------------------------------

1 service wants a resource of another service on behalf of owner

e.g. "Photo Printing Service"  wants to access "Photos" of "Karan Kaw" which are hosted at "Google Drive"

So, "Karan Kaw" wants two services to talk to each other and share some protected-resource (Photo) - limited resources for a limited amount of time

So, Owner is using a service of a client

Client asks access to "resource" from "resource-server", But "resource-server" redirected to Authentication Page where "Owner" is validates and he is asked for "Grant Access Permission" for the resources to "Client"

Once "owner" Okays, resource-server provides a JWT Token to Client 

Client then uses this "OAUTH JWT Token" to get access to resources as per allowed permissions whenever it wants, So its basically a "delegated authorisation" to Client from Owner to acess resources on his behalf from "resource-server"


OAUTH JWT Token is used because  This Token can't  be modified by anybody and it also has signature of Entity who created it.

-----------------------------------------------------------------------------

When trying to understand OAuth, it can be helpful to remember that OAuth scenarios almost always represent two unrelated sites or services trying to accomplish something on behalf of users or their software. All three have to work together involving multiple approvals for the completed transaction to get authorized.

-----------------------------------------------------------------------------

OAuth is a delegated authorization framework for REST/APIs. It enables apps to obtain limited access (scopes) to a user’s data without giving away a user’s password. It decouples authentication from authorization and supports multiple use cases addressing different device capabilities. It supports server-to-server apps, browser-based apps, mobile/native apps, and consoles/TVs.

You can think of this like hotel key cards, but for apps. If you have a hotel key card, you can get access to your room. How do you get a hotel key card? You have to do an authentication process at the front desk to get it. After authenticating and obtaining the key card, you can access resources across the hotel.

To break it down simply, OAuth is where:

App requests authorization from User
User authorizes App and delivers proof
App presents proof of authorization to server to get a Token
Token is restricted to only access what the User authorized for the specific App
-----------------------------------------------------------------------------
Protected-Resource/Resource -> Photos
Resource-Owner -> User(Me) 
Resource-Server -> Application2 ->
Client -> Application1 ->

-------------------------------------------------------------------
AuthServer/ResourceServer sends   "AuthToken" to  Client/Service1
Client/Service1 sends this token back to AuthServer and requests a AccessToken
AuthServer/ResourceServer sends "AccessToken" back to Client/Service1
Client/Service1 - will use this token - "AccessToken" to get access to Resources as directed by "AccessToken"

A little tweak 
Sometimes AuthServer can hand "AccessToken" directly instead of "AuthToken" followed by "AccessToken"
-------------------------------------------------------------------

Bearer Tokens are the predominant type of access token used with OAuth 2.0.

A Bearer Token is an opaque string, not intended to have any meaning to clients using it. 

Some servers will issue tokens that are a short string of hexadecimal characters, while others may use structured tokens such as JSON Web Tokens. 
-------------------------------------------------------------------

There are 3 Components in OAuth Mechanism–

OAuth Provider – This is the OAuth provider Eg. Google, FaceBook etc.
OAuth Client – This is the website where we are sharing or authenticating the usage of our information. Eg. GeeksforGeeks etc.
Owner – The user whose login authenticates sharing of information.
OAuth can be implemented via google console for “Login/Sign Up with Google” on a web app.
Pattern to be Followed –

  • Get OAuth 2.0 Client ID from Google API Console
  • Next, Obtain an access token from the Google Authorization Server to access the API.
  • Send the request with the access token to an API .
  • Get Refresh token if longer access is required.
-------------------------------------------------------------------



Bearer Tokens
Bearer Tokens are the predominant type of access token used with OAuth 2.0.
A Bearer Token is an opaque string, not intended to have any meaning to clients using it. 
Some servers will issue tokens that are a short string of hexadecimal characters, while others may use structured tokens such as JSON Web Tokens.

JSON Web Token (JWT, RFC 7519) is a way to encode claims in a JSON document that is then signed.
JWTs can be used as OAuth 2.0 Bearer Tokens to encode all relevant parts of an access token into the access token itself instead of having to store them in a database.


Bearer Authentication
Bearer authentication (also called token authentication) is an HTTP authentication scheme that involves security tokens called bearer tokens. The name “Bearer authentication” can be understood as “give access to the bearer of this token.” 
The bearer token is a cryptic string, usually generated by the server in response to a login request. The client must send this token in the Authorization header when making requests to protected resources:

Authorization: Bearer <token>

-------------------------------------------------------------------

Use Case - OAuth

OAuth is used in Microservices Communication
This OAUTH usage in Microservices is called - "Client Credentials Flow"
Clients here are really superDuper Trustworthy because We wrote it yourself

Service1   ---->    Service2[DB]
So, Each Service has a OAUTH Token - Which may be long living 


We cannot have each Microservice talking to another Microservice
So, We basically try to restrict that kind of communication
So, We basically have OAUTH tokens which help in that objective
----------------------------------------------------------------------
JWT - Json Web Token
JWT pronounced as - "JAWT" - Yes, There is 'A' in Sound 

JWT - is Base64 encoded Token

It has 3 parts - Header, Payload and Signature
Its contents are easily deciphered, so no private info should be inside it

Signature needs a key - which is possessed only by Auth Server
So, JWT can not be tampered with
It can be stolen as such as a whole by malicious person 
So care must be taken when we share JWT token

----------------------------------------------------------------------

No comments:

Post a Comment

Azure - Pipeline - Add Approver for Stage

https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass