Wednesday, December 30, 2020

SAML vs OAuth vs OpenIdConnect

 

SAML vs. OAuth

SAML (Security Assertion Markup Language) is an alternative federated authentication standard that many enterprises use for Single-Sign On (SSO). SAML enables enterprises to monitor who has access to corporate resources.

There are many differences between SAML and OAuth. 

  • SAML uses XML to pass messages, and OAuth uses JSON. 
  • OAuth provides a simpler mobile experience, while SAML is geared towards enterprise security. 
  • OAuth uses API calls extensively, which is why mobile applications, modern web applications, game consoles, and Internet of Things (IoT) devices find OAuth a better experience for the user. SAML, on the other hand, drops a session cookie in a browser that allows a user to access certain web pages – great for short-lived work days, but not so great when have to log into your thermostat every day.


OAUTH 2.0 Detailed Flow 





See Solid/Broken Lines 




OAUTH 2.0 Terminologies




OAuth Implicit Flow - See We actually handover Token directly over Front Channel 




Why We have "Authorization Code" and "Authentication Token" separate ?

  • Back Channel - A very secure Channel - Backend to Backend
  • Front Channel - A not very secure channel - Frontend to Backend


Overuse of OAUTH for Authentication? How to solve it ?




OAUTH  for Authentication is a hack 
OAUTH - is designed for Authorisation/Scope.
Social Login -> Google Login / Facebook Login -> Custom Solution - Overuse / Hack
Delegated Authorization - OAUTH - Solves it very Well
Designers of OAUTH Standard extended OAUTH and added Authentication capabilties and it  became - OpenIDConnect 
5-10% Extra Extension to OAUTH2.0 = OpenIdConnect



AccessToken - OAuth2.0
IdToken  - OpenIDConnect











User ---> OAUTH ---> SAML  use case [OAUTH + SAML , Together]


References




Public Key - Thumbprint

 How to check a certificate's thumbprint?

https://www.samltool.com/fingerprint.php  [Calculate Fingerprint]

https://knowledge.digicert.com/solution/SO9840.html


This tool calculates the fingerprint of an X.509 public certificate. A fingerprint is a digest of the whole certificate. In this case we use the SHA1 algorithm. Sometimes applications ask for its fingerprint, which easier for work with, instead of requiring the X.509 public certificates (a long string).

=====================================================

Using public key fingerprints for key authentication

Further information: key authentication

When a public key is received over an untrusted channel, such as the Internet, the recipient often wishes to authenticate the public key. Fingerprints can help accomplish this, since their small size allows them to be passed over trusted channels where public keys won't easily fit.


For example, if Alice wishes to authenticate a public key as belonging to Bob, she can contact Bob over the phone or in person and ask him to read his fingerprint to her, or give her a scrap of paper with the fingerprint written down. Alice can then check that this trusted fingerprint matches the fingerprint of the public key. Exchanging and comparing values like this is much easier if the values are short fingerprints instead of long public keys.

Dynamic JAXB - XSD Using Dynamic Entities

https://www.eclipse.org/eclipselink/documentation/2.5/solutions/jpatoxml006.htm#BEIDHGHI

https://www.eclipse.org/eclipselink/documentation/

https://www.eclipse.org/eclipselink/documentation/3.0/moxy/toc.htm


With EclipseLink MOXy, you can provide an existing XML schema from which to create a DynamicJAXBContext. EclipseLink will parse the schema and generate DynamicTypes for each complex type


https://www.eclipse.org/eclipselink/documentation/3.0/moxy/dynamic_jaxb.htm#sthref194



InputStream inputStream = myClassLoader.getSystemResourceAsStream("example/resources/xsd/customer.xsd");

DynamicJAXBContext dContext = DynamicJAXBContextFactory.createContextFromXSD(inputStream, null, myClassLoader, null);

 

DynamicEntity newCustomer = dContext.newDynamicEntity("example.Customer");

newCustomer.set("firstName", "George");

newCustomer.set("lastName", "Jones");

 

DynamicEntity newAddress = dContext.newDynamicEntity("example.Address");

newAddress.set("street", "227 Main St.");

newAddress.set("city", "Toronto");

newAddress.set("province", "Ontario");

newAddress.set("postalCode", "M5V1E6"); 

newCustomer.set("address", newAddress);

 

dContext.createMarshaller().marshal(newCustomer, System.out);


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

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

Azure - Pipeline - Add Approver for Stage

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