OAuth 2.0, OIDC, JWT

Transcript

1. OAUTH 2.0 | OIDC | JWT
2. What is AAA? ▪ Authentication - It is the process of verifying a user by validating their credentials i.e. username/email and password, OTP, digital certificates, biometrics etc. ▪ Authorization – It is the process of verifying what an authenticated user can access or actions they can perform. ▪ Accounting – It is keeping track of a user's activity while using the system to extract valuable information later e.g. forensics
3. OAUTH 2.0 • It enables a third-party application to obtain limited access to a HTTP service on behalf of a resource owner or on its own behalf • Before the protocol, one gave their username and password for one service to another so they could login to your account and grab whatever information they wanted. • There’s no guarantee that the service will keep your credentials safe or use for malicious purposes • The service won’t access more of your information than necessary. • Resource owner can’t revoke access to an individual third party without revoking access to all other third parties
4. Illustration Likes: • Music Dislikes: • Hassle of finding music he likes/might like • Not being up to date with latest music • Constantly downloading music • Filling sign up forms Solution • Use a music streaming service (Deezer) Ken
5. OAuth2.0 in action deezer.com Google accounts.google.com Email Password accounts.google.com Allow Deezer to access your profile details. No Yes deezer.com Hello Ken
6. Some Oauth2 Terminology (Roles) • Resource Owner – Entity capable of granting access to a protected resource e.g. end-user • Client – Application making protected resource request on behalf of the resource owner • Authorization Server – The server that authenticates a resource owner and issues access tokens to a client • Resource Server – The server hosting the protected resource
7. More Oauth2 Terminology • Access Token - the code that applications use to make requests to a resource server • Refresh token – Issued to client by authorization server and used to obtain new access token when the current token becomes invalid or expires • HTTP redirections – client or authorization server redirects a user-agent (Browser) to another destination • Redirect URI • Client Registration – Before initiating the protocol a client must be known to an authorization server • Client Types – confidential client (implemented on a secure server e.g. backend), public client (incapable of maintaining confidentiality of their creds e.g. PWA ,native app)
8. More Oauth2 Terminology… • Authorization Grant – refers to the way a client gets an access token 1. Authorization Code – client obtains an access token using an authorization code provided by authorization server 2. Implicit – auth server issues an access token directly to the client without requiring an authorization code 3. Resource Owner Password Credentials – resource owner credentials are used directly by the client, exchanged for a long-lived access token 4. Client Credentials – used when a client is acting on its own behalf i.e. it’s the resource owner
9. deezer.com Google accounts.google.com Email Password Client Authorization Server Resource Owner Go to authorization server redirect uri: deezer.com/callback scope: profile.read response type: code 1. Authentication Code Flow
10. deezer.com Google accounts.google.com Email Password accounts.google.com Allow Deezer to access your profile details. No Yes Client Authorization Server Resource Owner Go to authorization server redirect uri: deezer.com/callback scope: profile.read response type: code Request consent from the resource owner 1. Authentication Code Flow
11. deezer.com Google accounts.google.com Email Password accounts.google.com Allow Deezer to access your profile details. No Yes deezer.com Client Authorization Server Resource Owner Go to authorization server redirect uri: deezer.com/callback scope: profile.read response type: code Request consent from the resource owner Back to client using the redirect URI with an authorization code Authorization code: lwekfjweo 1. Authentication Code Flow
12. deezer.com Google accounts.google.com Email Password accounts.google.com Allow Deezer to access your profile details. No Yes deezer.com Client Authorization Server Resource Owner Go to authorization server redirect uri: deezer.com/callback scope: profile.read response type: code Request consent from the resource owner Back to redirect URI with an authorization code redirect uri: deezer.com/callback Authorization code: lwekfjweo Exchange authorization code for access token client id: skdfsdfds client secret: welfkwe authorisation code: lwekfjweo 1. Authentication Code Flow
13. deezer.com Google accounts.google.com Email Password accounts.google.com Allow Deezer to access your profile details. No Yes deezer.com profile.google.com Client Authorization Server Resource Owner Resource Server Go to authorization server scope: profile.read response type: code Request consent from the resource owner Back to redirect URI with an authorization code redirect uri: deezer.com/callback Authorization code: lwekfjweo Exchange authorization code for access token client id: skdfsdfds client secret: welfkwe authorisation code: lwekfjweo Talk to resource server using access token 1. Authentication Code Flow
14. deezer.com Google accounts.google.com Email Password accounts.google.com Allow Deezer to access your profile details. No Yes deezer.com Hello Ken profile.google.com Client Authorization Server Resource Owner Resource Server Go to authorization server redirect uri: deezer.com/callback scope: profile.read response type: code Request consent from the resource owner Back to redirect URI with an authorization code redirect uri: deezer.com/callback Authorization code: lwekfjweo Exchange authorization code for access token client id: skdfsdfds client secret: welfkwe authorisation code: lwekfjweo Talk to resource server using access token 1. Authentication Code Flow
15. deezer.com Google accounts.google.com Email Password accounts.google.com Allow Deezer to access your profile details. No Yes deezer.com Hello Ken profile.google.com Client Authorization Server Resource Owner Resource Server Go to authorization server redirect uri: deezer.com/callback scope: profile.read response type: implicit Request consent from the resource owner Back to redirect URI with an access token access token: lwekfjweo Talk to resource server using access token 2. Implicit Flow
16. Token Types • Bearer tokens - The request is not signed or encrypted. Possession of the bearer token is considered authentication. • MAC Tokens - More secure than bearer tokens, they’re like signatures, in that they provide a way to have (partial) cryptographic verification of the request.
17. Use cases So far…: • Simple login – Authentication • Single sign-on – Authentication • Mobile app login – Authentication • Delegated authorization (Using Scopes) - Authorization • Third-party Applications e.g. Albatross for Twitter • Developer APIs e.g. Google Calendar API (read/write)
19. Problems with OAuth 2.0 for Authentication • No standard way to get user information • Every implementation is a little different • No common set of scopes
20. OpenID Connect • Interoperable authentication protocol based on the OAuth 2.0 family of specifications. • It lets developers authenticate their users across websites and apps without having to own and manage password files. OAuth 2.o OpenID Connect What does it add? • ID token – provides identity • Standard scope • Standardized Implementations • User Info endpoint for getting more user information
21. deezer.com Google accounts.google.com Email Password accounts.google.com Allow Deezer to access your profile details. No Yes deezer.com Hello Ken Client Authorization Server Resource Owner Go to authorization server redirect uri: deezer.com/callback scope: openid response type: implicit Request consent from the resource owner Back to redirect URI with an access token and an id token access token: lwekfjweo id token: eiofelkfjewofjewklf
22. The ID Token • As with the OAuth flow, the OpenID Connect Access Token is a value the Client doesn’t understand. It is just a string of gibberish to pass with any request to the Resource Server. • The ID Token however, is very different. It is a JWT!! • It may still look like gibberish, but the Client can extract information embedded in the JWT such as your ID, name, when you logged in, the ID Token expiration, and if anything has tried to tamper with the JWT etc.
23. Same Use cases… So far…: • Simple login – Authentication (Open ID Connect) • Single sign-on – Authentication (Open ID Connect) • Mobile app login – Authentication (Open ID Connect) • Delegated authorization (Using Scopes) – Authorization (OAuth 2.0) • Third-party Applications • Developer APIs
25. JWT (JSON Web Token) “jot” • Their purpose is to transfer claims between two parties • Claims are definitions/assertions made about a certain party or object. Just Data. • Private claims – defined by users. avoid collisions with public claims • Public claims – claims registered with IANA JWT Claims registry • But why? It provides a standardized effort in form of a simple, optionally validated and/or encrypted container format • Applications: • Authentication • Client-Side (Stateless) sessions • Client-Side secrets
26. JWT in Detail (Elements/Structure) • Header – Has claims about the JWT i.e. algorithms used, whether signed or encrypted and how to parse the rest of the JWT • alg (algorithm used) • typ (media type) • Payload – Where the user data is usually located/added • iss (issuer) • sub (subject) • aud (audience) • exp (expiration) • iat (issued at) • jti (JWT ID) • Signature/Encryption – Dependent on algorithm used for signing/encryption. If unencrypted it’s omitted/optional
27. Unsecured JWTs eyJhbGciOiJub25lIn0. eyJzdWIiOiJ1c2VyMTIzIiwic2Vzc2lvbiI6ImNoNzJnc2IzMjAwMDB1ZG9jbDM2 M 2VvZnkiLCJuYW1lIjoiUHJldHR5IE5hbWUiLCJsYXN0cGFnZSI6Ii92aWV3cy9zZ XR0aW5ncyJ9. As there is no signature, it is simply an empty string . The dot is still added though
28. JSON Web Signature • The purpose of a signature is to allow one or more parties to establish the authenticity of the JWT • Validation is the process of checking a signature of a JWT. A token is considered valid when all restrictions specified in header and payload are satisfied e.g. alg, exp • Signed JWTs carry the additional signature element • Signing algorithms schemes include: HMAC (shared secret between parties), RSASSA (public private key)
29. Signed JWTs eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczovL2V4YW1wbG UuY29tLyIsInN1YiI6IlRoZSBXb3JsZCBJcyBOb3QgSW4gWW91ciBCb29rcyBBbm QgTWFwcy4gSXQgSXMgT3V0IFRoZXJlIiwiaWF0IjoxNjAxNDcwOTg2LCJleHAiO jE2MDE0NzQ1ODZ9.r9n_yKSli8oLTMt-Y_JiNsDuMaj13Uo880xdnyl5lJ0
30. JSON Web Encryption • Provides a way to keep data opaque/unreadable to third parties • Encrypted JWTS are sometimes nested: an encrypted JWT serves as the container of a signed JWT
31. Security Concerns/Considerations • Signature stripping - Common method for attacking a signed JWT is to simply remove the signature. Easily solved by making sure that the application that performs the validation does not consider unsigned JWTs valid. • Cross-Site Request Forgery (CSRF) - Attempt to perform requests against sites where the user is logged in by tricking the user’s browser into sending a request from a different site. JWTs, like any other client-side data, can be stored as cookies. Special headers that are added to requests only when they are performed from the right origin, per session cookies, and per request tokens. • Cross-site scripting (XSS) - Attempt to inject JavaScript in trusted sites. Injected JavaScript can then steal tokens from cookies and local storage. If an access token is leaked before it expires, a malicious user could use it to access protected resources. Any data received from clients must always be sanitized