Showing posts with label OpenID. Show all posts
Showing posts with label OpenID. Show all posts

Sunday 18 November 2018

SAML, OAuth and OpenID Connect

Rough Notes - Fix

OverviewSAML has been around for a fair amount of time  (roughly 8 years) and still is widely used for authentication and authorisation of end-users on the Internet.  OAuth2 is used to allow internet users to give internet/web-based applications access to the user's information without the user password.  OpenID Connect is an extension to OAuth2 and generally the way to go instead of SAML for user authentication.

Azure Active Directory Supports:
  1. SAML 2.0
  2. OAuth 2.0,
  3. OIDC, and
  4. WS-FED.
SAML:
  1. SAML is an umbrella standard that covers federation, identity management and single sign-on (SSO); and
  2. SAML is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based a markup language for security assertions.
Limitations of SAML:
1.       It was launched in November 2002 which supports SSO but has now been deprecated by a lot of auth suppliers.
2.       SAML is not supported with native Mobile Applications. Hybrid mobile apps can work with it.
3.       As it has now deprecated, finding it may not be supported by the latest technologies applications and technologies. 

OAuth 2.0:
1. Derived from OAuth, Auth2 uses 2 passwords and is more secure.
2. (Open Authorization) is a standard for authorization of resources. It does not deal with authentication. It was released in 2006.
Limitations of OAuth:
1.       It only deals in Authorization so we have a limitation that we cannot verify the user's identity, i.e. Authentication.


OpenID Connect:
  1. OpenID Connect (OIDC) is a protocol to verify user identities and get the user profile information. OIDC enables devices/apps to verify identities based on the authentication done by an authentication server
  2. It was launched in February 2014
  3. OpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0, an authorization framework
  4. OpenID Connect is built on top of OAuth 2.0, specifies a RESTful HTTP API, and uses JSON as a data format (JWT). It has a specialized set of predefined data types and endpoints for exchanging user information between the identity provider and the application.
  5. There are two different types of flows in OIDC, pick the appropriate flow, normally Code flow over implicit.
Advantages of OpenID Connect
1.       It supports SSO and federation.
2.       Has good support with .Net Core.
3.       It supports a wide range of clients like web applications, mobile apps and JavaScript applications.
4.       Have support with Azure AAD B2C as per Microsoft guidelines and others like Google+.

Comparing Differences:
  1. https://www.gluu.org/resources/documents/articles/oauth-vs-saml-vs-openid-connect/
  2. https://stackoverflow.com/questions/7699200/what-is-the-difference-between-openid-and-saml.
  3. https://www.quora.com/What-is-the-difference-between-OAuth-OpenID-and-OpenID-Connect

Support with Azure b2c
  1. https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-oidc-idp
Web sign-in with OpenID Connect in Azure Active Directory B2C
  1. https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/development/enabling-openid-connect-with-ad-fs
  2. https://docs.microsoft.com/en-us/aspnet/core/security/authentication/ws-federation?view=aspnetcore-2.2

Using Postman to Generate an OAuth Token Example


Using the Generated Bearer token in a get Request
Tip:  To examine a Bearer token use the website https://jwt.io 

Sunday 5 May 2013

Understanding OAuth

Overview:  With the introduction of Apps into the SharePoint 2013 world, OAuth is an essential mechanism to understand.  OAuth is a standard for authorisation of resources, it does not verify a users identity/Authentication.  This post explains in simple terms what OAuth is about.  The goal of OAuth is to allow Consumers (TweetAppFiction/my custom program) to use resources from a Service Provider (Twitter in this case).  For authentication purposes, the web application "TweetAppFiction" will redirect you to sign into Twitter on Twitters site, after you have logged into Twitter successfully, your browser is redirected back to "TweetAppFiction" with a token.  The token verifies who you are.  This allows your users to login to your site by using there large trusted websites credentials(FaceBook/Google/Yahoo), without them having to provide credentials to your new unknown site.

Tip: Replace TweetAppFiction with an app you are happy to consider as your consumer/app.  Examples of apps/consumer apps are TweetDeck and TweetApp

Problem:  So how OAuth shouldn't work: The end users signup with TweetAppFiction, TweetAppFiction asking the user for their Twitter, LinkedIn, Email etc. username and password.  TweetAppFiction now can work on your behalf with Twitter and the other Service Providers you have given.  The problem is you have given TweetAppFiction your full access credentials.  You don't know or trust "TweetAppFiction".  TweetAppFiction can now do any action it wishes against your Twitter account.  Another issue is if TweetAppFiction gets hacked, your Twitter credentials are compromised.

OAuth/OpenId stops the end-users creating another set of credentials by allowing the Service Provider e.g. Twitter for another website.  The end-user is directed to the Service Provider (twitter) where they authenticate themselves and tell the Service Provider (twitter) to allow this new web application to verify who they are (it also can give other permissions; in effect roles/services).

The issues OAuth solves for end-users are:
  1. TweetAppFiction does not have account credentials for your twitter account,
  2. TweetAppFiction will get access to do some actions on your behalf but you won't give it full permissions, and 
  3. The end-user can revoke TweetAppFiction's permissions at any point from the Service Provider (Twitter),
I see it as there being 2 parts to OAuth:
  1. Authorisation (setup TweetAppFiction with limited permissions to Twitter)
  2. Usage (TweetApp will post/use Twitters API's) 
To this point, we have been looking at authorisation.

Authorisation:  This is the setup of allowing the consumer (TweetAppFiction) to use a Service Provider (Twitter) on your behalf to verify end users. 
The end-user on the TweetAppFiction website/mobile app is going to create an account that logs you in using Twitter.  TweetAppFiction will send your browser a URL that allows you to go to Twitter, and give TweetAppFiction permissions.  If you are not already logged into Twitter you are prompted for your Twitter credentials.  Once you grant the permissions, Twitter sends TweetAppFiction a token (this in effect is a set of credentials and roles for TweetAppFiction to use that is not your username and password but has a limited set of functionality it can perform on your behalf).  Note: TweetAppFiction had to do an initial trust setup with Twitter that involves a Consumer Key & Consumer Secret (Think of this as the original trust relationship setup where Twitter is accepting TweetAppFiction to access TwittersOAuth API)/Resouce Server).  OpenId does not need to perform this initial connection step (Google and Yahoo use OpenId).

Trusted Usage:  For example, TweetAppFiction provides the ability to post comments on your behalf on Twitter.  To post a comment on your behalf, assuming you have already logged in, TweetAppFiction will use your Twitter provided "Access Token" to allow you to post Twitter comments from TweetAppFiction.

References:
https://www.pingidentity.com/blogs/pingtalk/2012/05/The-simple-joy-of-understanding-OAuth.html
http://www.slideshare.net/briandavidcampbell/is-that-a-token-in-your-phone-in-your-pocket-or-are-you-just-glad-to-see-me-oauth-20-and-mobile-devices

More Info:
Sahil Malik explains claims http://www.codemag.com/Article/1201021