- The username and the password are combined with a colon (
aladdin:opensesame). - The resulting string is base64 encoded (
YWxhZGRpbjpvcGVuc2VzYW1l).
Showing posts with label Authorization. Show all posts
Showing posts with label Authorization. Show all posts
Wednesday, January 13, 2021
Authorization Basic
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://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.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 UserUser 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
----------------------------------------------------------------------
Subscribe to:
Posts (Atom)