Downloaded 160 times
![JSON Object Signing & Encryption
(JOSE)
Working group: https://datatracker.ietf.org/wg/jose/charter/
• JWS – JSON Web Signatures
• JWT – JSON Web Token (pronounced “jot”)
• JWE – JSON Web Encryption
• JWA – JSON Web Algorithms
• JWK – JSON Web Key
{
"iss": "https://example.okta.com",
"sub": "00ugrenMeqvYla4HW0g3",
"aud": "w255HEWiSU4AuNxEjeij",
"iat": 1446305282,
"exp": 1446308882,
"amr": [
"pwd"
],
"auth_time": 1446305282,
"email": "karl@example.com",
"email_verified": true
}
Claims](/proxy?url=https%3A%2F%2Fimage.slidesharecdn.com%2Fwdrestserviceauthwithjwtsv12-151209014013-lva1-app6892%2F75%2FREST-Service-Authetication-with-TLS-JWTs-16-2048.jpg)
![JWT format
{
"alg": "RS256"
}
{
"iss": "https://example.okta.com",
"sub": "00ugrenMeqvYla4HW0g3",
"aud": "w255HEWiSU4AuNxEjeij",
"iat": 1446305282,
"exp": 1446308882,
"amr": [
"pwd"
],
"auth_time": 1446305282,
"email": "joe@example.com",
"email_verified": true
}
Header
Claims
Signature](/proxy?url=https%3A%2F%2Fimage.slidesharecdn.com%2Fwdrestserviceauthwithjwtsv12-151209014013-lva1-app6892%2F75%2FREST-Service-Authetication-with-TLS-JWTs-45-2048.jpg)
Uploaded byJon Todd
REST Service Authetication with TLS & JWTs
The document discusses the use of JSON Web Tokens (JWT) for service authentication and authorization, exploring concepts of claims-based authentication, federated identities, and TLS. It emphasizes the transition to a microservices architecture, where JWT enables stateless interactions and secure identity assertions across different services. The document also covers the technical specifications and practical implementations of JWT in the context of security and service interoperability.
In this document
Powered by AI
Introduction of presenters and Okta. Overview of the goals, including demystifying JWT authentication and providing code examples.
Discusses authentication (AuthN), authorization (AuthZ), and claims with an example of a boarding pass representing claims.
Explains the shift towards REST protocols, introduces JSON Web Tokens (JWT) and its relation to other standards like JWS and JWE.
Focuses on delegated access using OAuth 2.0, identity claims with JOSE, and outlines the service auth problem with comparison to monolithic models.
Describes TLS overview, handshake process, client authentication, and implications for internal services with certificates.
Demonstrates JWT encoding formats, signature types, and the layering of claims, outlining its application in practice.
Discusses implementing JWTs in an iterative manner, focusing on key rotation, security interceptors, and maintaining authorization.
Offers concluding thoughts, summarizes the importance of service and user authentication, and discusses how Okta can assist.
More Related Content
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](/proxy?url=https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Famazonauroratips-170307140000-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
![[H3 2012] OAuth2 - API 인증을위한 만능 도구상자](/proxy?url=https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fb5-oauth2api-121105213616-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Similar to REST Service Authetication with TLS & JWTs
![Don't Loose Sleep - Secure Your Rest - php[tek] 2017](/proxy?url=https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fdontloosesleep-secureyourrest-170524214928-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
REST Service Authetication with TLS & JWTs
- 1. Jon Todd @JonToddDotCom REST ServiceAuth with JWTs Wils Dawson @WilsDawson
- 2. About Okta Okta isthe foundation for secure connections between people and technology
- 3. Used in 185countries
- 4.
- 5. Goals 1. Demystify claimsbased auth with Json Web Tokens (JWT) 2. Learn how we solve service auth @Okta 3. Real world code example using Dropwizard
- 6. 1 Background • Concepts •The service auth problem 2 Service Auth 3 User Auth
- 7.
- 8. Verifying you arewho you say you are (AuthN) Authentication
- 9. What you areallowed to do (AuthZ) Authorization
- 10.
- 11. Identity attributes abouta user provided by a trusted issuer Examples: kerberos ticket, SAML assertion, JWT Claims
- 12. Boarding pass isa signed set of claims made by the airline about you • Issued by airline • Claims • Name (authentication) • Flight Date/Time, Number and Seating Priority (authorization) • Bar code/magnetic strip (signature) • Proves that the pass was issued by the airline and is not a forgery (authenticity). Claims example
- 13. OK, I getclaims. But why use JWTs?
- 14. Service protocol shiftto REST
- 15.
- 16. JSON Object Signing& Encryption (JOSE) Working group: https://datatracker.ietf.org/wg/jose/charter/ • JWS – JSON Web Signatures • JWT – JSON Web Token (pronounced “jot”) • JWE – JSON Web Encryption • JWA – JSON Web Algorithms • JWK – JSON Web Key { "iss": "https://example.okta.com", "sub": "00ugrenMeqvYla4HW0g3", "aud": "w255HEWiSU4AuNxEjeij", "iat": 1446305282, "exp": 1446308882, "amr": [ "pwd" ], "auth_time": 1446305282, "email": "karl@example.com", "email_verified": true } Claims
- 17. Single authentication trustedacross multiple separate systems Examples: WS-Federation, SAML, OpenID Connect Federation
- 18. Federation example • Atticket counter trade credentials for ticket (authentication broker) • Passport • Driver’s license • Agent at counter verifies credentials • ID issued by trusted source (trust) • Scans barcode and verifies photo (authentication) • Verifies flight is paid for and seat assigned (authorization) • Agent issues ticket (claims) • Ticket is accepted by multiple, independent parties (federation) • Security line entry • TSA check • Gate agent
- 19.
- 20. Federation standards shift https://www.flickr.com/photos/robbies/693510178 •JWS – JSON Web Signatures • JWT – JSON Web Token • JWE – JSON Web Encryption • JWA – JSON Web Algorithms • JWK – JSON Web Key JW-
- 21. Use cases Delegated accessOAuth 2.0 Identity claims JOSE OpenID ConnectFederation
- 22. OAuth 2 Framework RFC6749 Assertion Framework RFC 7521 Token Introspection RFC 7662 Token Revocation RFC 7009 Dynamic Client Registration RFC 7591 JSON RFC 7159 JSON Web Token Bearer Assertion RFC 7523 Proof Key for Code Exchange (PKCE) RFC 7636 Simple Authentication and Security Layer (SASL) RFC 7628 Token Exchange Draft SAML 2.0 Bearer Assertion RFC 7522 Proof of Possession Draft JSON Web Token (JWT) RFC 7519 JSON Web Signature (JWS) RFC 7515 JSON Web Encryption (JWE) RFC 7516 JSON Web Key (JWK) RFC 7517 Bearer Token RFC 6750
- 23. The service authproblem
- 24. Monolithic auth model SecurityInterceptors C o n t e x t GET https://myapplication.com/home AuthN Module Mobile Web API
- 25. Monolithic auth model GEThttps://myapplication.com/home Security Interceptors C o n t e x tUser Module Events Module AuthN Module Homepage Module Log eventsLookup user Mobile Web API
- 26. Services auth model- context Event Service Security Interceptors User Service Security Interceptors AuthN Service Security Interceptors Homepage Service Security Interceptors Authorization: Bearer <token> GET https://myapplication.com/home Authorization: Bearer <token> Authorization: Bearer<token> C o n t e x t Lookup user ID with token Mobile Web API
- 27. Services auth model- claims Event Service Security Interceptors User Service Security Interceptors AuthN Service Security Interceptors Homepage Service Security Interceptors Authorization: Bearer <jwt> Authorization: Bearer <jwt> Authorization: Bearer <jwt> { “userId”:”…”, “tenantId”:”...”, “scope”:”PROFILE_READ” } Issues access jwt after authN Claims example Concepts • Claims • Authentication broker • Federation Mobile Web API
- 28. Layers of security Perimeter Service EventService Security Interceptors User Service Security Interceptors AuthN Service Security Interceptors Homepage Service Security Interceptors Authorization: Bearer <claims_token> User
- 29. 1 Background 2Service Auth • TLS overview • Adding AuthZ • Demo 3 User Auth
- 30.
- 31. What is TLS? •Secure Sockets Layer (SSL) Transport Layer Security (TLS) • Symmetric cryptography for data encryption • Protection against failure via MAC • Identity of communicating parties via asymmetric cryptography
- 32. TLS handshake ClientServer 2 Server Hello (with cert) 4 Finished 5 Finished Secured Channel Client Hello 1 3 Calculate Symmetric Key 3 • Hello • Key Exchange • Finished https://upload.wikimedia.org/wikipedia/commons/thumb/4/46/Diffie- Hellman_Key_Exchange.svg/2000px-Diffie-Hellman_Key_Exchange.svg.png
- 33. Who’s authenticated? Event ServiceUserService Homepage Service Hello Hello, here’s my certificate Secured Channel User Service
- 34. TLS client authentication Client Server 2 ClientCertificate Request 4 Certificate Verify 5 Calculate Key and Finish Secured Channel Hello 1 3 Client Certificate 1 5 • Client talking to authentic server • Server talking to known client • Requires client to have certificate
- 35. That’s a lotof certificates Event ServiceUser Service Homepage Service • Enable support for multiple acceptable public keys • Consider using a key hierarchy • Rotating User CA requires change only to User Service • Enable revocation checking Root CA (offline) User CA Event CA Homepage CA
- 36. Problem solved? Event ServiceUserService Homepage Service User Service ISS: Root CA Event Service ISS: Root CA Homepage Service ISS: Root CA
- 37.
- 38. Hostname verification • Standard(RFC 2818) • Match hostname of client to certificate • Hard when services share hosts like in a cluster manager Subject: C=US, ST=California, L=San Francisco, O=Acme Inc, OU=Engineering, CN=homepage03.internal.acme.com Homepage Service
- 39. Service-name verification • Tiecertificates to services rather than hosts • Better portability • Simpler deployments • No standard • Application level Subject: C=US, ST=California, L=San Francisco, O=Acme Inc, OU=Engineering, CN=dev.homepage-service Homepage Service
- 40. TLS client authenticationfor internal services http://developer.okta.com/blog/ More info?
- 41.
- 42. So we’re doneright? Event Service Security Interceptors User Service Security Interceptors AuthN Service Security Interceptors Homepage Service Security Interceptors Mobile Web API
- 43. 1 Background 2Service Auth 3 User Auth • JOSE • In practice • Demo
- 44.
- 45. JWT format { "alg": "RS256" } { "iss":"https://example.okta.com", "sub": "00ugrenMeqvYla4HW0g3", "aud": "w255HEWiSU4AuNxEjeij", "iat": 1446305282, "exp": 1446308882, "amr": [ "pwd" ], "auth_time": 1446305282, "email": "joe@example.com", "email_verified": true } Header Claims Signature
- 46. JWT encoding base64url(Header) +“.” + base64url(Claims) + “.” + base64url(Signature) eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2V4YW 1wbGUub2t0YS5jb20iLCJzdWIiOiIwMHVncmVuTWVxdll sYTRIVzBnMyIsImF1ZCI6IncyNTVIRVdpU1U0QXVOeEV qZWlqIiwiaWF0IjoxNDQ2MzA1MjgyLCJleHAiOjE0NDYz MDg4ODIsImFtciI6WyJwd2QiXSwiYXV0aF90aW1lIjoxN DQ2MzA1MjgyLCJlbWFpbCI6ImthcmxAZXhhbXBsZS5jb 20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZX0.XcNXs4C7Dq pR22LLti777AMMVCxM7FjEPKZQndAS_Cc6R54wuQ5EA puY6GVFCkIlnfbNmYSbHMkO4HL3uoeXVOPQmcqhNPD LLEChj00jQwZDjhPD9uBoNwGyiZ9_YKwsRpzbg9NEeY8 xEwXJFIdk6SRktTFrVNHAOIhEQsgm8 Header Claims Signature
- 47. JWA - signaturetypes HMAC (Symmetric) Digital Signature (Asymmetric)
- 48. JWS – symmetrickeys Event Service Security Interceptors User Service Security Interceptors AuthN Service Security Interceptors Homepage Service Security Interceptors Symmetric Key
- 49. JWS – asymmetrickeys Event Service Security Interceptors User Service Security Interceptors AuthN Service Security Interceptors Homepage Service Security Interceptors Public key Private key
- 50. JOSE onion claims signed claims encryptedclaims • JWS – JSON Web Signatures • JWT – JSON Web • JWE – JSON Web Encryption • JWA – JSON Web Algorithms • JWK – JSON Web Key JWT – Composes: JWA & JWK JWS JWE Reference
- 51.
- 52. Iterative rollout Mobile WebAPI Security Interceptors C o n t e x tEvents Module AuthN Module Homepage Module User Service Security Interceptors Authorization: Bearer <JWT> Generate JWT
- 53. Iterative rollout Security Interceptors AuthNService User Service Security Interceptors Authorization: Bearer <JWT> Event Service Security Interceptors Homepage Service Security Interceptors Authorization: Bearer <JWT> Authorization: Bearer <JWT> Cookie / Token Mobile Web API
- 54. Key Rotation • Enablesupport for multiple acceptable public keys • Consider using a key hierarchy • Rotating AuthN CA requires change only AuthN service • Enable revocation checking Root CA (offline) Auth CA Event Service Security Interceptors User Service Security Interceptors AuthN Service Security Interceptors Homepage Service Security Interceptors Public key Private key
- 55. JWT Java Libraries https://openid.net/developers/libraries/#jwt •Jose4j • Nimbus JOSE + JWT • Java JWT • Resteasy • Apache Oltu - JOSE
- 56.
- 57.
- 58. Recap • Service authwith TLS • Transport level privacy and authentication • Service level authorization • User auth with JWTs • JWT • Stateless • Scalable • Authentication broker • Converts existing external identity attributes into internal claims • Internal claims enable federation across microservices • Code: https://github.com/wdawson/dropwizard-auth- example
- 59. How can Oktahelp? Universal Directory Single Sign-On Provisioning Adaptive Multi-factor Authentication Social Authentication Inbound Federation AD and LDAP Integration
- 60. Thank You Jon Todd @JonToddDotCom WilsDawson @WilsDawson
Editor's Notes
- #5 Use the right tool for the job Backend server stack is almost entirely Java with use of Jetty and Dropwizard to get a flavor of some of the tools
- #13 Transition: OK, I get claims. So if claims have been around in for such a long time why do people care about JWTs?
- #15 Clean
- #20 The concept of federation is very broad As it relates to microservices/SOA, the idea is that as you break a system up, federation provides a model for services to
- #21 Just as we’ve traded in angle brackets for curlies the industry has moving from WS-* to OIDC It’s starting to look like the Deathstar isn’t it? The OpenID space isn’t without it’s own comical abbreviations: But they certainly are more appetizing
- #25 Security interceptors Validates AuthN is still valid Validates user in context has correct permissions to access resource (AuthZ) Context supplies authenticated user in context and permissions to all the other code in the monolith AuthN module – code which knows how to authenticate a user. If interceptor determines user’s needs authentication AuthN module Notice how AuthN is typically centralize but AuthZ decisions are distributed across the codebase
- #27 REST is stateless, we have no more shared context so how are we going to pass User info along to each service? Naive approach is with the same random token we’ve been using
- #28 We can solve the context problem with baking important attributes into the claims token to prevent lookups Now that we have a centralized AuthN service, we can extend the federation with claims
- #29 For the remainder of the talk we’re going focus on applying this federated claims based approach to auth. In particular, we’re going to focus on backend service auth and we’re going to make the assumption that your services are talking HTTP Important to note that while we are addressing client auth scenarios in this talk, the model we’ll be putting place naturally extends to the client following the OAuth model Layers: Perimeter – outside the scope of this presentation Host – host level authentication and transport level security with TLS User -
- #32 SSL predecessor Secure key exchange = symmetric data exchange use symmetric Message Authentication Code Public key crypto for authentication
- #33 Hello = what do we support? Key exchange = Where the magic happens, cipher dependent. “Master secret” & paint Finished = encrypted test
- #34 Back to our services… What just happened? Cert offering = authentication Could be anyone: Another service An attacker So what can we do?
- #35 Client extra step = verify can access private key Trust root is better than client, rotation opens attack vector
- #36 Quick word about certificates… How do we manage those certificates? A few things to consider, eveyone is different. Multiple acceptable keys means rotation is easier Key hierarchy means rotation is easier Multiple ways to do this For this talk, we’ll assume offline root, services underneath that Revocation checking = easier rotation & required for rotation Ok so, we’ve given our services each their own certificate that has a trust chain up to our root. Let’s go back to the TLS client authentication
- #37 Not quite. Since they are all signed by the root, and that’s what we’re trusting, Event Service can still talk. Ways around this, like not trusting root, but then we have rotation issues like I just talked about. What are my options if I want to trust the root, but don’t want the event service to talk? AuthZ: We’ve estabilished “Who you are” now we want to know “What can you do?”
- #39 ”HTTP over TLS” standard RFC Client Server && Server Client If your services share hosts = harder Wildcard or subjectAltName extension Depending on environment, don’t solve the problem
- #40 Portability any host works Deployments no special config per host No standard .. sadface Application level Regex Authoritative, omnipotent service
- #43 We can solve the context problem with baking important attributes into the claims token to prevent lookups Now that we have a centralized AuthN service, we can extend the federation with claims
- #49 Audience question: What’s a security drawback of the symmetric key approach?
- #54 Walk the flow Clients continue to use existing auth mechanism AuthN Module converts external session / token representations into internal JWT Potential future updates Consider OpenID Connect at the client level Remove homepage service entirely Generate service specific access tokens up in the client (Oauth 2.0)
- #56 There are a number of great options We use Nimbus JWT Add our own policy on certificate revocation checking
- #59 JWT Stateless no need for a DB user info Scalable No need to query a DB to check if the token is valid No need to call other services for data already computed in the token
- #60 At the core we make it easier to adopt cloud 3000 customers using Okta to connect with cloud apps Adobe developer built the creative cloud auth on top of Okta for federated enterprise authentication Companies already have their own AD or LDAP. Okta makes getting on to using CC faster and easier Advent Universal directory per customer