![[APIdays INTERFACE 2021] The Evolution of API Security for Client-side Applic...](https://cdn.slidesharecdn.com/ss_thumbnails/apidays-interface-johannstalk-210709062455-thumbnail.jpg?width=560&fit=bounds)
Ad
More Related Content
What's hot (20)
Similar to Demystifying AuthN/AuthZ Using OIDC & OAuth2 (20)
![[WSO2Con USA 2018] Identity APIs is the New Black](https://cdn.slidesharecdn.com/ss_thumbnails/wso2conusa18identityapisisthenewblack-180718104220-thumbnail.jpg?width=560&fit=bounds)
Ad
More from NGINX, Inc. (20)
Ad
Recently uploaded (20)
Demystifying AuthN/AuthZ Using OIDC & OAuth2
- 1. Demystifying OIDC & OAuth2 Rajesh Bavanantham Solutions Architect
- 2. | ©2019 F52 Solutions Architect Rajesh Bavanantham • OIDC Configuration • Ingredients of token(s) • Authentication flow • Authorization Agenda
- 3. | ©2019 F53 What makes me keep going during this lockdown Just doing whatever “SHE” says
- 4. | ©2019 F54 Terminology OP – OpenID Provider RP – Relying party AuthN – Authentication. First party apps- Apps developed & maintained by the Enterprise. Third party apps – Apps developed & maintained by our partners/customers. OIDC – OpenID Connect User Journey – A flow to show how a user interacts with your apps (domain)
- 5. | ©2019 F55 TerminologyContinued… Resource Credentials – ClientID & SecretKey User Credentials – UserName & Password AuthZ – Authorization. Entitlements – Elevated or appropriated access Claims – Defined inside the token(s) as both informational and for verification OIDC grants - AuthCode + PKCE OAuth2 grants – Client credentials
- 6. | ©2019 F56 • Around 50% of the Layer 7 vulnerabilities are with weak AuthN and poor AuthZ CONFIDENTIAL API Security Economy Source: edgescan 2019 Vulnerability Statistics Report
- 7. | ©2019 F57 • Traditional approach for AuthN are primary target for credential stuffing CONFIDENTIAL API Security Economy Source: edgescan 2019 Vulnerability Statistics Report
- 8. | ©2019 F58 • External hacking remained the largest threat actor (69%) • Threat action (53%) respectively for data breaches • Up to 75% of all credential abuse attacks against the financial services industry targeted APIs directly • 55,141,782 malicious login attempts in 2019 CONFIDENTIAL API Security Economy Source: Imperva - The State of Vulnerabilities Report 2019
- 9. | ©2019 F59 OIDC Configuration
- 10. | ©2019 F510 OpenID Connect Configuration Endpoint • RFC for OIDC configuration endpoint – https://openid.net/specs/openid-connect-discovery-1_0.html • Google OIDC Configuration endpoint – https://accounts.google.com/.well-known/openid-configuration • Salesforce OIDC Configuration endpoint – https://login.salesforce.com/.well-known/openid-configuration
- 11. | ©2019 F511 CONFIDENTIAL
- 12. | ©2019 F512 Scope vs Claims Scope openid Claims "aud", "exp”, "iat", "iss", "sub”, “jti”, “nbf”
- 13. | ©2019 F513 Scope vs Claims Scope openid profile Claims "aud","exp", "iat", "iss", "sub", ”jti", ”nbf", "family_name","middle_name""given_name","local e","picture","organization_id,"picture","preferred_u sername","nickname","updated_at","user_id"
- 14. | ©2019 F514 Scope vs Claims Scope openid profile email Claims "aud","exp", "iat", "iss", "sub", ”jti", ”nbf", "family_name","middle_name""given_name","local e","picture","organization_id","picture","preferred_u sername","nickname","updated_at","user_id”, "email","email_verified"
- 15. | ©2019 F515 Ingredients of Token(s)
- 16. | ©2019 F516 Standard Access Token as JWT { "sub": "1008092044", "iss": "https:// idp.blah.com /authz/v1/", "aud": "https://api.blah.com /consumers/", "nbf": 1524225722, "exp": 1524226622, "iat": 1524225722, "jti": "3119f745-2d40-4455-a6df-97b1ad7b4d71", }
- 17. | ©2019 F517 Summary of Scope & Claims Scope Claims profile requests access to default profile claims email requests access to email and email_verified claims address requests access to address claim phone requests access to phone_number and phone_number_verified claims
- 18. | ©2019 F518 Standard Access Token with Profile & Custom Claims { "sub": "1008092044", "iss": "https:// idp.blah.com /authz/v1/", "aud": "https://api.blah.com /consumers/", "nbf": 1524225722, "exp": 1524226622, "iat": 1524225722, "jti": "3119f745-2d40-4455-a6df-97b1ad7b4d71", "given_name": "firstName", "family_name": "lastName", "email": [email protected] "user_metadata": { “crm_reference": ”d34343dfdt6dfd” } ”app_metadata": { “product_name": ”ProductA” } }
- 19. | ©2019 F519 JWT Standard Claims Used For Description Type iss To validate who is the issuer of the token Issuer Validate sub To identify the user uniquely Subject Informational aud To validate the recipients of the tokens. Used to restrict which API can use the token Audience Validate exp To validate the expiry of the supplied token Expiry Validate nbf To validate the token that it shouldn’t be used before a specified time Not Before Validate iat Gives information about when the token was created Issued at Informational jti Unique identifier of a JWT which would be used to revoke the token in API Gateway JWT Id Validate
- 20. | ©2019 F520 Token(s) Matrix
- 21. | ©2019 F521 Access Token Token Types JWT Opaque Mandatory Used For Expiry Time Validation Comments access_token YES YES YES Must be only used to access resources 10-15 minutes • Client can choose not to validate and can solely rely on API Gateway or IDP to validate. • If JWT is not produced by IDP, then IDP should provide oauth2-introspection endpoints to verify the opaque token – Refer https://tools.ietf.org/html/rfc7662. • API Gateway must validate access_token with default claims like exp, iat, aud, and iss. • Services should validate access_token with default claims like exp, iat, aud, and iss and custom claims like roles and groups if supplied expiry of access_token shouldn’t be more than 10-15 mins.
- 22. | ©2019 F522 Id Token Token Types JWT Opaque Mandatory Used For Expiry Time Validation Comments id_token YES NO NO Must be only used to identify the user detail Identical to access_ token • id_token must be validated by the client • No entity should fail if id_token is not supplied • In some cases, client choose to send id_token along wit access token to supply user details, API Gateway should verify at_hash claim in the id_token to see whether those tokens are produced for same user along with the access_token • if its supplied, id_token must be validated by the services – Signature and expiry validation. id_token can accompany access_token as add-on, if supplied by the IDP. However, it shouldn’t be used to access resources
- 23. | ©2019 F523 Refresh Token Token Types JWT Opaque Mandatory Used For Expiry Time Validation Comments refresh_token NO YES NO Can be only used to request new access_ token upon expiry of access_ token Expiry of refresh_ token will be greater than access_ token * refresh_token can request new access_token upon expiry of the existing access_token. It will be RP’s responsibility. It could be API Gateway or Mobile/Devices • Expiry time can be configured depending on the use case. For mobile/devices it is recommended to have expiry time for months to give better use experience. However, refresh_token needs to be protected with pass pin to be used by the user. • For web apps used by consumers, expiry should be slightly higher than access_token – 5 minutes • For web apps used in the POS terminals by employees, expiry can be up to a days a week • Don’t request for new token until the token is expired
- 24. | ©2019 F524 AuthN Flows
- 25. | ©2019 F525 Easier migration for existing apps which relies on session authn to integrate with APIs. If third party apps are browser-based apps and if they need long running tokens (eg stores accessing resources) , this AuthCode grant must be implemented on their server for secure token exchange. If client is a browser-based App, then they can’t store client_id & secret_key securely. Grant type OIDC AuthCode grant should be used Use Case for First Party Web Apps for AuthN
- 26. | ©2019 F526 CONFIDENTIAL Gateway as RP – AuthCode Grant
- 27. | ©2019 F527 When first party or third party native mobile apps requires AuthN. When user is required to login. Grant type used OIDC Auth Code grant along with PKCE - Proof Key for Code Exchange Use Case for Mobile Devices (Native Apps) for AuthN
- 28. | ©2019 F528 Native Mobile App as RP – AuthCode Grant + PKCE
- 29. | ©2019 F529 Where users are not involved in integrating first party or third-party systems to the resource server. Grant type used OAuth2 Client credential grant Use Case for System to System AuthN
- 30. | ©2019 F530 Since this authn is not originated from a user, the token which is created by the IDP for a user should not be used to access other API resources. It can be mitigated by using an OIDC standard claim called “aud”. System AuthN Pattern – OAuth2 Client Credential Grant
- 31. | ©2019 F531 Authorization Coarse & Fine Level AuthZ
- 32. | ©2019 F532 • Whether user have a valid token to consume resources • Token is not expired – exp • Token is not used before it meant to – nbf • Token has the issuer which APIGateway trust – iss • Token is signed by the issuer and token is not tampered by the user – signature • Token has a valid audience which defines whether the token can be presented against a resource or not Coarse Level Authorization
- 33. | ©2019 F533 • Any other checks that happens with the user level or app level which was not taken care by coarse level authorization. • Mostly fine level authorization are like • Custom User claims − RBAC – Role based access control. • Custom App claims − Terms & Condition − Profile info to consume the app Fine Level Authorization
- 35. | ©2019 F535 • Custom scope must have namespace – preferably uri that identify which product the consumer App is requesting for. • https://www.blah.com/v1/customers/ • Custom scope can also be extended to request elevated access for the app and user • https://www.blah.com/v1/customers/customers.delete • https://www.blah.com/v1/customers/customers.admin How to Present Custom Scope in a Request for Fine-level Authorization OR
- 36. | ©2019 F536 How Does App Request Standard Scopes GET /authorize?response_type=code &scope=openid profile email &client_id=s6BhdRkqt3 &state=af0ifjsldkj &redirect_uri=https%3A%2F%2Fptop.only.wip.la%3A443%2Fhttps%2Fclient.example.org%2Fcb
- 37. | ©2019 F537 How Does App Request Standard & Custom Scopes OIDC for Fine-level Authorization GET /authorize?response_type=code &scope=openid profile email https://www.blah.com/v1/customers.admin &client_id=s6BhdRkqt3 &state=af0ifjsldkj &redirect_uri=https%3A%2F%2Fptop.only.wip.la%3A443%2Fhttps%2Fclient.example.org%2Fcb
- 38. | ©2019 F538 { "sub": "1008092044", "iss": "https://idp.blah.com/authz/v1/", "aud": "https://api.blah.com/consumers/", "nbf": 1524225722, "exp": 1524226622, "iat": 1524225722, "jti": "3119f745-2d40-4455-a6df-97b1ad7b4d71", "given_name": "firstName", "family_name": "lastName", "email": [email protected] "user_metadata": { “crm_reference": ”d34343dfdt6dfd” } ”app_metadata": { “v1/customers”: { “roles”: “admin” } } } Example 1: Token with Standard & Custom Claims
- 39. | ©2019 F539 { "sub": "1008092044", "iss": "https://idp.blah.com/authz/v1/", "aud": "https://api.blah.com/consumers/", "nbf": 1524225722, "exp": 1524226622, "iat": 1524225722, "jti": "3119f745-2d40-4455-a6df-97b1ad7b4d71", "given_name": "firstName", "family_name": "lastName", “Scope” : “admin” "email": [email protected] "user_metadata": { “crm_reference": ”d34343dfdt6dfd” } } Example 2: Token with Standard & Custom Claims
- 40. | ©2019 F540 • There will be two endpoint for each resources if we need to give elevated access to a user. • For example if we want to give ability for users to read, update & create their own customers data and admin access to delete a customer record. GET POST PUT DELETE /customers/v1 DELETE /customers/v1/admin/delete • Different authentication mechanism for admin endpoints to protect admin endpoints. General Approach for Role Based Authorization Now
- 42. | ©2019 F542 • Resource representation should be around bounded business context. • HTTP methods should represent what a user is intended to act upon a resource, NOT the endpoints. GET /v1/customers/{customer-id} ==> Read POST /v1/customers /{customer-id} ==> Create PUT /v1/customers /{customer-id} ==> Update DELETE /v1/customers/{customer-id} ==> Delete Recommendation
- 43. | ©2019 F543 Having user journey where you could identify your users and personas that would interact with your business resources. This is an ongoing task Simplify your role definition – depends on your domain User Admin Guest Anonymous Identify Your User Journey
- 44. | ©2019 F544 CONFIDENTIAL User and Persona for Order Domain
- 45. | ©2019 F545 • Generalized Roles should come from IDP • Isolate permissions from IDP • Relevant apps should map roles to permissions (scalable) Role ! = Permissions
- 46. | ©2019 F546 CONFIDENTIAL Best Practices for Using access_token (while producing & accessing) •No PII data in the access_token , whatsoever... •Have shorter expiry time for the access_token if the token is issued to untrusted client(browser) – 2 - 5 mins. •Always make your client applications to request with scope and let your IDP set the right audience the access_token is intended for. •Don't overuse access_token - meaning don't use the same access_token to access all the resources in your environment. Be specific with aud claim where it should be used, and gateways can reject the access if the token is not intended to access that specific resource. •Sign the token centrally in your IDP where you can rotate Private/Public key periodically. API Gateway should be smart enough to cache the public key from the IDP for the verification and could detect key rotation done by the IDP on the fly.
- 48. CONFIDENTIAL