Wanted to share my DevTeach Montreal 2017 talk where I talked about OAuth and OpenId Connect. The types of OAuth Grants, how to consume them, the flows in OAuth and what OpenId Connect comes into play, what does it solve.
Hope you like the presentation and if you are interested in more security topics, ping me and let me know what would you be interested in.
Transcript
1. OAUTH2 & OPENID CONNECT DEMYSTIFIED Taswar Bhatti (Microsoft MVP) GEMALTO @taswarbhatti http://taswar.zeytinsoft.co m taswar@gmail.com
2. WHO AM I?? – 4 years Microsoft MVP – 17 years in software – Author of Instant Automapper (Packt) – Currently working at as System Architect at Enterprise Security Space (Gemalto) – You may not have heard of Gemalto but 1/3 of the world population uses Gemalto but they just dont know that
3. WHAT WE WILL COVER TODAY? OAuth 2.0 OAuth flows OpenID JWT (JavaScript Web Token) some says “jot” OpenID Connect Demo (Keycloak IDP)
4. WHAT IS OAUTH? An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.
5. OAUTH HISTORY OAuth started circa 2007 2010 – RFC 5849 defines OAuth 1.0 2010 – OAuth 2.0 work begins in IETF Working deployments of various drafts & versions at Google, Microsoft, Facebook, Github , Twitter, Flickr, Dropbox … Mid 2012 – Lead author and editor resigned & withdraws his name from all specs (DRAMA……) October 2012 – RFC 6749, RFC 6750
6. THE GOOD OAuth 2.0 is easier to implement than OAuth 1.0 Wide spread and continue growing Shorted lived token Encapsulated Token OAuth2 makes it HTTP/JSON friendly to request and transmit tokens Takes “multiple client” architectures into account Clients can have varying trust levels
7. OAUTH 2.0 – Transport Security : Using HTTPS and TLS – Ease : Usable (no digital certs to verify) – Flexible : Mobile, Web SPA apps, etc – Decoupled: Resource server and authorization server – Bearer Token : Easy for integration; Id Token also known as keys 9/24/2017 7
8. SO I CAN USE MY PASSWORD??? 9/24/2017 8
9. OAUTH IS LIKE A VALET KEY – Provides another domain delegated access to your application server resources 9/24/2017 9
10. OAUTH ROLES 9/24/2017 10 User Application API
11. OAUTH ROLES 9/24/2017 11 User Application API
12. OAUTH MISCONCEPTION Ohh this is easy!! When I login to Spotify with Twitter, it grabs by username and password from Twitter…. Wrong !!!!!!!!!!!!!! 9/24/2017 12 Developer
13. OAUTH IS NOT FOR 9/24/2017 13 – Traditional Access Control – Not for authentication – Not for Federation – OAuth should be used for delegation
14. BEARER TOKEN GET /somedata HTTP/1.1 Host: someserver.com Authorization: Bearer a3b4c55cf The access token can be JWT format – A security token with the property that any party in possession of the token (a “bearer”) can use the token in any way that any other party in possession of it can 9/24/2017 14
15. OAUTH TERMINOLOGY – Client or Consumer Application : Is typically a web based or mobile application that wants to access User’s Protected Resources – Resource Server or the Resource Provider: Is a web site or web service API where the User keeps his/her protected data – Authorized Server : The server issuing access tokens to the client after successfully authenticating the resources and obtaining authorization – User or the Resource Owner : Is a member of the Resource Provider, wanting to share certain resources with a third party – Client Credentials : Are the consumer keys and consumer secret used to authenticated the Client – Tokens : are the access token generated by server after request from client
16. OAUTH TOKEN TYPES – Access Token : Used to directly access protected resources on behalf of a user or service – Refresh Token : When given to an authorization server, it will give you a new access token – Authorization Code Token : Use only in the authorization code grant type for access token or refresh token 9/24/2017 16
17. HIGH LEVEL FLOW OF OAUTH 2 – An app registers him/herself on an oauth service provider (lets say twitter) – S/he gets an app key/secret for each app that s/he registers – When users login they are redirected to the service provider to provide the credentials – If user approves then a token is issued to the app for a limited time – Finally the client uses the token to access the resource
18. OAUTH USAGE In OAuth [authorization] You are in BigPhotoPrintingCorp.net account and you need to access your images from AwesomeImage.com site BigPhotoPrintingCorp.net site will redirect you to AwesomeImage.com site You enter you credential to AwesomeImage.com site and authenticated your self. This is like in openId AwesomeImage.com site will ask if you want to give permission to access only photos of AwesomeImage.com site you select yes AwesomeImage.com site will redirect back to BigPhotoPrintingCorp.net site BigPhotoPrintingCorp.net can access AwesomeImage.com site
19. GRANTING THE WRONG PERMISSIONS 9/24/2017 19
20. 4 TYPES OF OAUTH FLOW Authorization Code Grant : for apps running on a web server, long lived tokens Implicit Grant : For browser-based or mobile apps, during user is logged in, short lived tokens Resource Owner Credentials Grant : For logging in with a username and password, trusted application Client credentials Grant : for application access machine to machine
21. AUTHORIZATION CODE FOR APPS RUNNING ON A WEB SERVER This is the most common type of application you have when dealing with OAuth servers. Web apps are run on a server where the source code of the application is not available to the public. This case your site will REDIRECT you to particular authorization server. If webserver making multiple request it can use STATE parameter for map callback response with request One of the most complicated one in OAuth
22. YOU HAVE SEEN THIS BEFORE 9/24/2017 22
23. IMPLICIT FOR BROWSER-BASED OR MOBILE APPS Browser-based apps run entirely in the browser after getting source code from a web server. Since the entire source code is available to the public, they cannot maintain the confidentiality of their client secret, so the secret is not used in this case One will make api calls with the token that is assign to it For mobile apps also cannot maintain the confidentiality of their client secret. Because of this, mobile apps must also use an OAuth flow that does not require a client secret. With this concept token is exposed to local operating system. So there are no refresh tokens.
24. PASSWORD FOR LOGGING IN WITH A USERNAME AND PASSWORD OAuth 2 also provides a “password” grant type which can be used to exchange a username and password for an access token directly. This obviously requires the application to collect the user’s password. As a result users may hesitate to use this service unless this app comes from the auth service provider. Only used in highly trusted application, your social media Facebook app, rather than 3rd party apps (Batman Fancy Facebook app)
25. MEET THE ACTORS IN OUR OAUTH 9/24/2017 25 Resource Owner Or User Application Authorization Server Resource Server Or API
26. CLIENT CREDENTIALS FOR APPLICATION ACCESS There are scenarios that applications may wish to get statistics about the users of the app. In this case, applications need a way to get an access token for their own account, outside the context of any specific user. OAuth provides the client credentials grant type for this purpose. This is machine to machine communication sort of concept
27. 9/24/2017 27
28. TOKEN – CLIENT CREDENTIAL GRANT $ curl –XPOST https://api.mysite.com/oauth/token -d ‘grant_type=client_credentials’ -d ‘client_id=TestClient’ -d ‘client_secret=TestSecret’ 9/24/2017 28
29. TOKEN – CLIENT CREDENTIAL GRANT Response from Authorization Server { “access_token”:”03807cb390319329bdf6c777d4dfae9c0d3b3c35″, “expires_in”:3600, token_type”:”bearer”, “scope”:null } 9/24/2017 29
30. PASSWORD GRANT TYPE 9/24/2017 30
31. PASSWORD GRANT $ curl –XPOST https://api.mysite.com/oauth/token -d ‘client_id=TestClient’ -d ‘client_secret=TestSecret’ -d ‘grant_type=password’ -d ‘username=batman’ -d ‘password=nananananananannaBatman’ 9/24/2017 31
32. SCOPES AKA PERMISSIONS – Roles, Authority where you want to give access control to who can do what with it – The name of permissions – User scopes – Client/Applications Scopes – Token contains intersection 9/24/2017 32
33. SCOPES 9/24/2017 33 CarKey.Ignite
34. SCOPES 9/24/2017 34 CarKey.OpenTrunk CarKey.Ignite
35. SCOPES IN TOKEN Response from Authorization Server { “access_token”:”03807cb390319329bdf6c777d4dfae9c0d3b3c35″, “expires_in”:3600, token_type”:”bearer”, “scope”: “CarKey.Ignite” } 9/24/2017 35
36. AUTHORIZATION CODE GRANT TYPE 9/24/2017 36
37. AUTHORIZATION GRANT $ https://fancy.mysite.com/oidc #Reaching out to application, are you logged in? 302 HTTP Redirect https://api.mysite.com/authorize?response_type=code&client_id=Te stClient&redirect_uri=https://fancy.mysite.com/oidc 9/24/2017 37
38. AUTHORIZATION CODE GRANT GET /oauth/authorize #Login to the app SUCCESS you get back a code HTTP 302 redirect back to redirect_uri https://fancy.mysite.com/oidc?code=SplxlOBeZQQYbYS6WxSbIA&stat e=xyz 9/24/2017 38
39. AUTHORIZATION CODE GETTING THE TOKEN $ curl –XPOST https://api.mysite.com/oauth/token -d ‘client_id=TestClient’ -d ‘client_secret=TestSecret’ -d ‘grant_type=authorization_code’ -d ‘code=SplxlOBeZQQYbYS6WxSbIA’ 9/24/2017 39
40. ACCESS TOKEN Response from Authorization Server { “access_token”:”03807cb390319329bdf6c777d4dfae9c0d3b3c35″, “expires_in”:3600,“ token_type”:”bearer”, “scope”: “CarKey.Ignite” } 9/24/2017 40
41. RESOURCE SERVER CHECK TOKEN – If it is a Jwt token you can verify the key who signed it – Endpoint to check the token returning the scopes to verify if valid token 9/24/2017 41
42. IMPLICT GRANT TYPE – Used for clients that can easily be impersonated like phone or mobile application – 3rd party application – A simplified Authorization Code Grant with eliminating the code step – Access token is given directly to the app – No Refresh Token are given, Access token are short lived – Requires Resource Owner to invoke for new Access Token 9/24/2017 42
43. IMPLICIT GRANT FLOW
44. OPENID Sharing a single Identity with different consumers Decentralized OpenID is a form of Single Sign On (SSO) OpenID is a URL http://myname.myopenid.com
45. WHAT CAN YOU DO? One can claim and prove they own the openid Use it for authentication At a high level its like Microsoft Passport It’s a form of authentication, if you have a system you still will need to populate your fields (e.g firstname, email, etc) OpenId does not provide you with those information
46. OPENID USAGE In OpenId [authentication] You want to access your account on bigcorp.net bigcorp.net is asking your openId You entered your username for openId bigcorp.net will redirect you to the your openid providers site User give password to openId provider and authenticate him/her self openId provider will redirect user back to bigcorp.net site bigcorp.net will grant you to access your account
47. OPENID CONNECT We have talked about OAuth and OpenId and there is also OpenId Connect It’s the new SSO authentication for the internet OpenId Connect build on top of OAuth2 since sometimes you may just need authentication Remember OAuth2 is for authorization OpenID Connect provides Implict flows and Authorization code flow
48. OPENID CONNECT FLOW – SIMPLE 9/24/2017 48
49. OPENID CONNECT TOKEN { “sub” : “alice”, “user_name” : “Taswar” “iss” : “https://openid.c2id.com”, “aud” : “client-12345”, “auth_time” : 123456789, “iat” : 1311280970, “exp” : 1311281970, “email” : Taswar@gmail.com, “phone_number”: 123-4567 } 9/24/2017 49
50. OPENID CONNECT – HYBRID 9/24/2017 50
51. JWT (JAVA 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 JavaScript Object Notation (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 MACed and/or encrypted.
52. JWT CONT JWT Token looks like this eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjEzODY4OTkxMzEsI mlzcyI6ImppcmE6MTU0ODk1OTUiLCJxc2giOiI4MDYzZmY0Y2ExZTQx ZGY3YmM5MGM4YWI2ZDBmNjIwN2Q0OTFjZjZkYWQ3YzY2ZWE3OTdi NDYxNGI3MTkyMmU5IiwiaWF0IjoxMzg2ODk4OTUxfQ.uKqU9dTB6gK wG6jQCuXYAiMNdfNRw98Hw_IWuA5MaMo Ok great…………. Once you understand the format, it’s actually pretty simple: .. [header].[payload].[signature]
53. JWT CONT In other words: You create a header object, with the JSON format. Then you encode it as a base64 You create a claims object, with the JSON format. Then you encode it in base64 You create a signature for the URI. Then you encode it in base64 You concatenate the three items, with the “.” separator
54. BENEFITS JSON Web Tokens work across different programming languages: JWTs work in .NET, Python, Node.js, Java, PHP, Ruby, Go, JavaScript, and Haskell. So you can see that these can be used in many different scenarios. JWTs are self-contained: They will carry all the information necessary within itself. This means that a JWT will be able to transmit basic information about itself, a payload (usually user information), and a signature. JWTs can be passed around easily: Since JWTs are self-contained, they are perfectly used inside an HTTP header when authenticating an API. You can also pass it through the URL.
55. HEADER The header carries 2 parts (JWT and the hashing algorithm like below) { “typ”: “JWT”. “algo”, “HS256” } Then base64 encode it
56. PAYLOAD & CLAIMS The payload will carry the bulk of our JWT, also called the JWT Claims. This is where we will put the information that we want to transmit and other information about our token. There are multiple claims that we can provide. This includes registered claim names, public claim names, and private claim names. { “iss”: “taswar.zeytinsoft.com”, “exp”: 1300819380, “name”: “Taswar Bhatti”, “admin”: true }
57. SIGNATURE The third and final part of our JSON Web Token is going to be the signature. This signature is made up of a hash of the following components: the header the payload Secret The secret is the signature held by the server. This is the way that our server will be able to verify existing tokens and sign new ones. var encodedString = base64UrlEncode(header) + “.” + base64UrlEncode(payload); HMACSHA256(encodedString, ‘secret’);
58. ENDPOINTS OF OPENID CONNECT Authorization Endpoint (Regular OAuth) Identity Endpoint (username/pass, hardware token, biometrics) UserInfo Endpoint (name, birthday, picture, etc) Optionals (Session Endpoint, WebFinger etc)
59. OPENID CONNECT TOKENS The OpenID Connect server provides client applications with two key tokens: ID token – asserts the users identity in a signed and verifiable way. Access token – provides access to the user’s details at the UserInfo endpoint and other protected web APIs.
60. DEMO
61. THANK YOU Questions? Contact: Taswar@gmail.com Blog: http://Taswar.zeytinsoft.com Twitter: @taswarbhatti And a special thanks to Lego Batman !