CIS13: Authorization Agent (AZA) Mobile Protocol
2 likes•1,345 views
The document discusses the need for a single sign-on (SSO) experience for enterprise employees using both native and web applications, as current OAuth patterns create a high usability burden. It introduces a solution involving an 'authorization agent' (aza) that allows users to collectively authorize multiple native applications in one step, streamlining the token acquisition process. The document also highlights the importance of standardization and interoperability among various technology providers to support this SSO functionality.
CIS13: Authorization Agent (AZA) Mobile Protocol
- 1. Na#ve Single SignOn Interop Demonstra#on Cloud Iden#ty Summit 2013 1
- 2. Mo#va#on • Enterprise employees use mul#ple applica#ons (combo of web & na#ve) in their jobs • Applica#ons both hosted on-‐prem & SaaS • Current reality is that an SSO experience limited to the browser apps • But na#ve applica#ons becoming more and more prevalent • Poten#ally significant usability burden for employees
- 3. Default OAuth paNern for na#ve applica#ons • Employee authen#ca#on/authorizes each applica#on individually • Authoriza#on manifested as the issuance of an OAuth token to each na#ve app – this presented on subsequent API calls to corresponding server • Employee interacts with each OAuth AS (corresponding to each API) to obtain an OAuth token
- 4. Implica#ons of default paNern • Employee bears burden of authen#ca#ng/ authorizing each na#ve applica#on separately • Even if done infrequently, may be unacceptable • Each SaaS must directly support OAuth (running an Authoriza#on Server) • Enterprise distanced from employee's use of na#ve applica#ons
- 5. Na#ve App SSO Alterna#ve • An employee is able to collec#vely authorize each na#ve applica#on on device in one step • Rather than each applica#on individually obtaining OAuth tokens for itself the tokens are obtained on behalf of those na#ve applica#ons by a dedicated 'authoriza#on agent' (AZA) • Employee authorizes the AZA, which then proceeds to obtain for other applica#ons the necessary access tokens • Once handed the tokens, na#ve applica#ons use them as normal on API calls • For user, enables an SSO experience for na#ve applica#ons
- 6. AZA Alterna#ve 6 Enterprise SaaS Device Browser Na#ve SaaS SaaS2 Na#ve SaaS2 AS AS Client Client AZA
- 7. AZA Alterna#ve 7 Enterprise SaaS Device Browser Na#ve SaaS SaaS2 Na#ve SaaS2 AS AS Client Client AZA AS
- 8. SaaS AZA Alterna#ve 8 Enterprise Device Browser AZA AS Browser Na#ve SaaS AZA Na#ve SaaS2 SaaS2
- 9. Alterna#ve 9 Enterprise Device Browser Na#ve SaaS SaaS AZA Na#ve SaaS2 SaaS2 AS
- 10. Implica#ons 1. Na#ve apps must be able to request access tokens of a local AZA 2. AZA must be able to request access tokens on behalf of another na#ve applica#on 3. AZA must be able to hand over access tokens to na#ve applica#on 4. RS must be able to validate access tokens (poten#ally issued by a remote AS) 10
- 11. Standardiza#on • Mul#ple pieces (from different providers) implies need for standards • A number of industry players working to profile/extend OpenID Connect for the AZA<-‐ >AS interac#on – New WG being formed in OpenID Founda#on • Related but separate effort to standardize App<-‐> AZA messaging emerging
- 12. Interoperability • We are demonstra#ng interoperability between different AZAs, OAuth ASs, na#ve applica#ons, and OAuth RSs • The AZA<-‐>AS protocol is based on OAuth (not the eventual OIDC-‐based standard) • MobileIron & Ping also implemented a back-‐ channel authoriza#on query interface 12
- 14. Interop Scenarios 14 AZA AS AZA AZA AS