OAuth Base Camp

2,063 views
1,864 views

Published on

What should today's students of computer science know about the new topics OAuth and OpenID Connect? This presentation addresses this question. It was given as a guest lecture at the Karlsruhe Institute of Technology.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,063
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

OAuth Base Camp

  1. 1. OAuth Base CampLecture, Karlsruhe Institute of Technology, 2013-05-22Dr. Oliver Pfaff© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  2. 2. PrefaceIT-Security - A Jigsaw Puzzle with Many Pieces© iC Consult GmbH 2013 - Dr. Oliver PfaffAuthorization▶ Today’s focus: authorization For individually owned Webresources Discretionally managed bytheir resource owners▶ The discussed mechanismaddresses a key use case It needs to be combined withother security mechanismsto deliver sound solutions -engineered security It needs to be implementedwith care to avoid eventualbreaches – secure engineeringSingle-Sign-OnInfrastructureAuthenticityKeymanagementThreats/RisksConfidentialityUser/entityauthenticationCoding
  3. 3. Contents▶ User authorization▶ OAuth▶ Demonstration▶ Key observation▶ Generalizations User authentication App authentication Grant types Kinds of tokens IAM styles▶ Conclusions© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  4. 4. User AuthorizationConsidered Use Case▶ Individual, access-protected resources used by third-party providers In the interest of resource owners, adding value for them Not: legal entity-owned resources or public resources▶ Examples: Post to your feed at Facebook Get your contacts or calendar from Google Get your location information from a mobile provider …© iC Consult GmbH 2013 - Dr. Oliver PfaffYouApplicationYour resourcesWeb containerHTTPHTMLHTMLWebbrowserYouruser agentYour service providerApplicationWeb containerHTMLHTTPThird-party provider,JSON,XML
  5. 5. User AuthorizationRelevance of this Use Case▶ Web APIs are a key driver behind current innovation in the Internet Mindset: others might have cool ideas about what could be done with yourassets – facilitate their integration Examples: Web API directory Buzzwords: API economy, mash-ups, composite applications, REST…▶ Ability to work with individual, access-protected resources is a key concern With public resources only, the potential behind Web APIs would getexhausted quickly Fundamentally important© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  6. 6. User AuthorizationCoverage for this Use Case▶ Chickens – some birds just don’t fly: IT-security: fiddle with authentication credentials• Assign end-user credentials to clients in a mashup (which authnthemselves as end-users)• Assign service provider credentials to them (which authn end-usersthemselves and call as super-users) IAM: use enterprise authorization approaches• Utilize long-lived authorization policy objects established a-priori andmanaged out-of-band (from the browsing sessions of users) IT-security and IAM mechanisms as known/established until mid of last decadenot do the desired trick© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  7. 7. User AuthorizationHow to Fill the Gap?© iC Consult GmbH 2013 - Dr. Oliver Pfaff▶ Real-world analogy: valet parking keys Master key: all vehicle features Valet key: opens doors, starts engine but does not open luggage/glovecompartments, limits speed…▶ Useful when trusting (discretionary powers) an attendant (third-party) topark (limited use) the own car (resource)▶ A Web-equivalent to valet parking keys would help: means that allow ownersof Web resources to delegate resource access to third-parties in discretionary fashion and a constrained way (time, functional scope…)
  8. 8. OAuthOverview▶ OAuth defines a resource authorization protocol that allows resource owners todelegate resource access rights to third-parties in a discretionary fashion witha limited functionality, for a limited time▶ The OAuth specifications are developed by the IETF User AuthorizationProtocol (oauth) working group: The OAuth 2.0 Authorization Framework RFC 6749, 2012 The OAuth 2.0 Authorization Framework: Bearer Token Usage RFC 6750, 2012 An IETF URN Sub-Namespace for OAuth RFC 6755, 2012 OAuth 2.0 Threat Model and Security Considerations RFC 6819, 2013 Plus several draft documents – work-in-progress▶ The specifications care about simple things: How to obtain a token to access resources? How to use such tokens?▶ Note: in the following OAuth 2.0 is considered. The term ‘OAuth’ refers to version2.0 by default (predecessor: The OAuth 1.0 Protocol RFC 5849, 2010)© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  9. 9. OAuth(Super)Simplified▶ With 3 assumptions: Individual, access-protected resources Third-party consumers HTTP▶ in 1 sentence: 3-party resource authorization protocol allowing resource ownersto delegate access rights dynamically and in-band (with their browsing sessions)▶ and in 1 diagram:© iC Consult GmbH 2013 - Dr. Oliver PfaffResourceownerResourceproviderResourceconsumer3. Present user authz1. Request user authz2. Establish user authz
  10. 10. OAuthThe First Trick – User-Managed Authorization© iC Consult GmbH 2013 - Dr. Oliver PfaffOAuth-protectedresource endpointResourceownerResource consumerResource providerAuthorization serverPost/Get/Put/Delete withaccess_token200 OK with<Resource>Resourceclient30x Redirect withcode (URL query param)Bold: objects/endpoints specified by OAuthUser authnand consentdialogues: exchanges specified by OAuthAuthorizationendpoint30x Redirectwith scope(URL query param)RedirectionendpointTokenendpointPost with clientcreds, code (application/x-www-form-urlencoded)200 OK withaccess_token(application/json)Tokenclient
  11. 11. OAuthA User Authentication Protocol?▶ Resource consumers do not get information about the Authentication (method, time, authority…) established for the current user Identity (identifiers, attributes, affiliations…) of the current user▶ They can not challenge for certain methods of authentication, levels of assurance… OAuth does not define a protocol for user authentication in distributedsystems (attention: this refers to the native authorization code grant shownabove; things gets more subtle with OAuth extensions and additional grants)© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  12. 12. OAuthCore Abstractions▶ Authorization grants: credentials that refer to resource owner’s authorizationand that are presented in requests to OAuth token endpoints▶ Protocol endpoints (RFC 6749): Authorization endpoint Token endpoint Redirection endpoint▶ Protocol messages (RFC 6749): Authorization requests and responses - via HTTP redirection• Request parameters: response_type, scope etc.• Response parameters: code etc. Token requests and responses• Request parameters: grant_type, scope etc.• Response parameters: access_token etc.▶ Resource request authentication: Bearer (RFC 6750) MAC (draft-ietf-oauth-v2-http-mac-03.txt) OAuth (RFC 5849)© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  13. 13. OAuthExtension Points▶ Authorization grants: new grants e.g. JWT/SAML 2.0 bearer assertions definedby OAuth (draft-ietf-oauth-jwt-bearer-05.txt, draft-ietf-oauth-saml2-bearer-16.txt)▶ Protocol endpoints: new endpoints e.g. TokenRevocation for token revocation purposes defined by OAuth (draft-ietf-oauth-revocation-07.txt) Introspection for discovering token metadata (draft-richer-oauth-introspection-04.txt) TokenInfo for token validation and discovery purposes provided by e.g.Google (https://accounts.google.com/o/oauth2/tokeninfo)▶ Protocol messages: New messages e.g. revocation request/response defined for token revocationpurposes by OAuth (draft-ietf-oauth-revocation-07.txt) New parameters e.g. request resp. id_token in authorization request resp.authorization/token response messages defined by OIDC for userauthentication purposes New values e.g. id_token resp. profile, offline_access of the OAuth-defined response_type resp. scope parameters defined by OIDC▶ Resource request authentication: new schemes© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  14. 14. OAuthRevocation▶ Of OAuth tokens: Short-lived objects to access resources Supporting their revocation is based on an additional endpoint and is optional(draft-ietf-oauth-revocation-07.txt implementations should support therevocation of access tokens)▶ Of OAuth refresh tokens: Long-lived objects to refresh OAuth tokens Supporting their revocation is based on an additional endpoint and is optional(draft-ietf-oauth-revocation-07.txt implementations must support therevocation of refresh tokens)▶ Of objects storing granted authorizations by end users: Long-lived objects governing OAuth tokens/refresh tokens issuance Such objects are not specified by OAuth. It is common practice to provideWeb UIs for revoking these objects. For instance:• Google: Authorized Access to your Google Account• Facebook: App requests and activity© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  15. 15. OAuthAdoption▶ AT&T: AT&T APIs use OAuth 2.0▶ Facebook: Graph API uses OAuth 2.0▶ Flickr: Flickr APIs use OAuth 1.x▶ Google: Google APIs use OAuth 2.0▶ LinkedIn: LinkedIn API supports OAuth 2.0 and 1.x▶ Microsoft: Live Connect uses OAuth 2.0, Windows Azure esp. Windows Azure AD Access Control supports OAuth 2.0▶ Salesforce: Force.com and Salesforce.com APIs use OAuth 2.0▶ Telefonica: BlueVia APIs use OAuth 2.0 as well as OAuth 1.x▶ Tumblr: Tumblr API uses OAuth 1.x▶ Twitter: Twitter API uses OAuth 1.x▶ Xing: Xing API uses OAuth 1.x▶ Yahoo: Yahoo APIs use OAuth 1.x▶ Yammer: Yammer APIs use OAuth 2.0▶ …and many others. Note that some do abstain: Amazon Web Services: "Do you support SAML or OAuth? Not at this time…"© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  16. 16. DemonstrationAccessing OAuth-Protected Web APIs at Google▶ Chosen OAuth-protected resource: User info endpoint: https://www.googleapis.com/oauth2/v1/userinfo▶ OAuth authz server: Token endpoint: https://accounts.google.com/o/oauth2/token Authz endpoint: https://accounts.google.com/o/oauth2/auth▶ Resource consumer: DIY clients embedded in an own Web application: Servlet: GoogleConnectServlet Embedded clients: UserInfoServiceClient, OAuthTokenServiceClient Third-party libraries: esp. Apache HttpClient, Google GSON▶ Demonstration approach: Common client code prepared upfront OAuth-specific code evolves stepwise© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  17. 17. 302 FoundHTTP GetHTTP PostHTTP GetDemonstrationWeb APIs that Will Be Called© iC Consult GmbH 2013 - Dr. Oliver PfaffWebbrowserGoogleTokenendpointAuthorizationendpointOAuth-protectedUserInfo endpointhttps://accounts.google.com/o/oauth2/authhttps://www.googleapis.com/oauth2/v1/userinfohttps://accounts.google.com/o/oauth2/tokenAuthorization serverGoogleConnectServletUserInfoServiceClientOAuthTokenServiceClientRedirectionendpoint
  18. 18. DemonstrationImplementation Remark▶ To keep the code compact, the same servlet class is used to implement: OAuth redirection endpoint: respond to subsequent requests from useragents – triggered by redirects from OAuth authorization endpoints:GET /…/GoogleConnectServlet?code=4VrjQAl…&state=79e26d… HTTP/1.1 OAuth enforcement point: respond to initial requests from user agents –triggered by user action:GET /…/GoogleConnectServlet HTTP/1.1▶ This results in following code skeleton:if (needsUserLogin(httpServletRequest, httpServletResponse)) {try {// Provides the OAuth redirection endpoint// Completes OAuth user authorization exchange// Conducts OAuth token and UserInfo exchanges} catch (UserAuthorizationNeededException e1) {// Provides the OAuth enforcement point// Initiates OAuth user authorization exchange} catch (OtherException e2) {// Take care}// Do work for authn user}© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  19. 19. DemonstrationImportant Links for this Example▶ User-facing links: Manage granted authorizations:https://accounts.google.com/b/0/IssuedAuthSubTokens▶ Developer-facing links: Manage Google API clients: https://code.google.com/apis/console/ Using OAuth to access Google APIs:http://code.google.com/apis/accounts/docs/OAuth2.html User info Web API documentation:• For Web applications as callers:https://developers.google.com/accounts/docs/OAuth2Login• For AJAX clients/mobile apps as callers:https://developers.google.com/accounts/docs/OAuth2UserAgent Cryptographic checksum validation keys (concerns ID Token objects):https://www.googleapis.com/oauth2/v1/certs© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  20. 20. DemonstrationDitto for Facebook▶ User-facing links: Manage granted authorizations:http://www.facebook.com/settings?tab=notifications&section=application_notification▶ Developer-facing links: Manage Facebook API clients: https://developers.facebook.com/apps Using OAuth to access Facebook APIs:http://developers.facebook.com/docs/reference/api/data-access/ User info Web API documentation:• For Web applications as callers:https://developers.facebook.com/docs/howtos/login/server-side-login/• For AJAX clients/mobile apps as callers:https://developers.facebook.com/docs/howtos/login-with-facebook-using-ios-sdk/https://developers.facebook.com/docs/getting-started/facebook-sdk-for-android/3.0/#enablesso Cryptographic checksum validation keys: n.a.© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  21. 21. Key ObservationComplexity Is Distributed Unevenly▶ OAuth client complexity: small - in the example: Resource exchange: OAuth token sent as URL query parameter Token exchange: authorization code sent as form-encoded bodyparameter along with client id/secret (client authentication). OAuth tokenreceived in response body (form-factor: JSON) Authorization exchange: client id and scopes sent and authorization codereceived in URL query parameters▶ OAuth server complexity: large OAuth client run-time:• Web APIs: OAuth-protection of resource endpoints, OAuth endpoints• Web UIs: authenticate and authorize, manage granted authorizations OAuth client build-time:• Web APIs resp. UIs: register/manage API clients Unlike most other security and IAM protocols, OAuth distributes complexityunevenly. This is a feature as it helps developers to integrate© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  22. 22. Key ObservationIs Client Simplicity a Problem?▶ No, not all tokens are the same – just as in the real-world:© iC Consult GmbH 2013 - Dr. Oliver Pfaff Tokens issued by notaries to claim real estate:▶ Having a variety between low and high-end mechanisms presents a value▶ IT-security in industry is about managing risks: One needs to understand the• value/exposure of assets• protection offered by security mechanisms One needs to create a sound matching, not:• Secure mechanism (e.g. notary tokens) for low-value items (baggage)• Insecure mechanism (e.g. hotel tokens) for high-value items (real estate) Tokens issued by hotels to reclaim baggage:
  23. 23. Generalizations – User AuthenticationOpenID Connect Overview▶ OpenID Connect defines a user authentication protocol on top of OAuth 2.0: ID token objects: JWT objects that report about authentication events UserInfo service: RESTful service to query authenticated information aboutthe current user; protected by OAuth▶ The specifications are developed by the OIDF (work-in-progress): Basic Client Profile OIDF implementers draft, 2013 Implicit Client Profile OIDF implementers draft, 2013 Messages OIDF implementers draft, 2013 Standard OIDF implementers draft, 2013 Discovery OIDF implementers draft, 2013 Dynamic Client Registration OIDF implementers draft, 2013 Session Management OIDF implementers draft, 2013▶ The specifications care about simple things: How to obtain a token that asserts the authenticated identity of a caller? How to use such tokens?▶ False friend: OpenID Connect is no new flavor of the OpenID 2.0 protocol–it is anew protocol for user authentication in distributed systems© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  24. 24. Server-side transfer of stateGeneralizations – User AuthenticationThe Second Trick: Server-Side SSO© iC Consult GmbH 2013 - Dr. Oliver Pfaff© iC Consult GmbH 2013 - Dr. Oliver PfaffWebbrowserAuthorization serverGet withaccess_token200 OK with30x Redirect withcodeUser authnand consentdialoguesAuthorizationendpoint30x Redirectwith scopeRedirectionendpointTokenendpointPost with clientcreds, code200 OK withaccess_tokenTokenclientIdentity consumerIdentity providerGet inputs by tokenGet inputs by codeBold: objects/endpoints specified by OIDC : exchanges specified by OIDC,id_tokenUserInfo(application/json)OAuth-protectedUserInfo endpointUserInfoclientandvalue openid
  25. 25. Generalizations – User AuthenticationAbstractions Added by OpenID Connect▶ OAuth authorization request extensions : Parameter values e.g. id_token Parameters to instruct on how to conduct user authentication• With a simple value: e.g. display/prompt• With a complex value: Request objectso Based on JWT (draft-ietf-oauth-json-web-token-07.txt)o Matching samlp:AuthnRequest objects with respect to purpose▶ OAuth authorization resp. token response extensions: Parameters to report about user authentication• With a complex value: ID token objectso Based on JWTo Matching saml:Assertion objects with respect to purpose▶ UserInfo service: RESTful Web service Standard claims for UserInfo service responses© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  26. 26. Generalizations – User AuthenticationClassifying OpenID Connect▶ OIDC is a user authentication protocol based on OAuth – others that inheritfrom OAuth are also feasible. Common recipe: Expose a Web API that provides authenticated information about the currentuser Protect this Web API by means of OAuth▶ This creates the problem of telling OIDC apart from other OAuth-based userauthentication protocols▶ A protocol for federated IdM can be called OIDC iff it utilizes OAuth 2.0 (RFC 6749) with bearer tokens (RFC 6750) accordingthe authorization code or implicit grants presents the value openid in the OAuth scope parameter of its OAuthauthorization request messages presents OIDC ID Token objects in either the OAuth authorization (implicitgrant) or the OAuth token response messages (code grant)© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  27. 27. Generalizations – User AuthenticationExamples▶ Login with Facebook: OAuth-based user authentication protocol, not OIDC Authorization exchange: no support of the value openid in the OAuth scopeparameter (cf. Permissions for supported scope values) Token exchange: conducted via HTTP GET, no JSON response, no ID Tokenobjects provided▶ Login with Google: OIDC© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  28. 28. Client-sidetransferofstateGeneralizations – App AuthenticationThe Third Trick: Client-Side SSO© iC Consult GmbH 2013 - Dr. Oliver PfaffOAuth-protectedresource endpointe.g. GMailMobilebrowserResource providerAuthorization serverAuthorizationendpointTokenendpointMobile deviceMobileapp200 OKFeed(text/xml)Post/Get/Put/Delete with access_tokenUser authnand consentdialogues30x Redirects withscope, codeSomemechanism topass OAuthcreds
  29. 29. Generalizations – App AuthenticationObstacles on the Way…▶ How to conduct user login/consent dialogues? Rely on mobile browser Embed WebView component Provide own user login/consent UIs in mobile app▶ Which grants for acquiring OAuth tokens? Authorization code, implicit, resource owner password credentials Refresh token Others▶ Which OAuth credentials to pass? Authorization codes Tokens▶ How to pass OAuth credentials? Document titles Cookie headers Others▶ Care is needed - a one-size-fits-all solution for authenticating users of mobileapps and providing SSO experience to them does not yet exist© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  30. 30. Generalizations – Grant TypesOAuth Token Acquisition▶ RFC 6749: Authorization code: 3-party token acquisition with authorization codesbased on explicit user authorization for confidential clients (Web applications) Implicit: 3-party token acquisition based on explicit user authorization forpublic clients (AJAX clients, mobile apps) Resource owner password credentials: 2-party token acquisition based onuser credentials without explicit user authorization (for migration purposes) Client credentials: 2-party token acquisition based on client credentialswithout explicit user authorization Refresh token: 2-party token acquisition based on refresh tokens withoutexplicit user authorization▶ Bearer profiles (IETF oauth WG drafts): JWT/SAML 2 bearer: 2-party token acquisition based on JWT/SAML 2.0bearer assertions (‘bearer grants’) without explicit user authorization▶ Proprietary extension grants e.g.: Google+ one-time-code: achieves the effects of the authorization code andimplicit grants in a single flow Microsoft ACS bearer types: predecessors of JWT/SAML 2 bearer …© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  31. 31. Generalizations – Kinds of TokensToken Zoo▶ Purposes: Authz purposes: access tokens, refresh tokens (RFC 6749) - tokens withdefined purpose but undefined contents – implementations define contents Authn purposes: ID tokens (OIDC) - tokens with defined purpose andcontents – claims about authentication event▶ Types: Opaque: tokens with contents that are opaque to token consumers (resourceendpoints) - coupling them to token producers Self-contained: tokens with contents that can be processed by tokenconsumers - decoupling token producers and consumers▶ Security: PoP: tokens that can only be used if accompanied by a PoP e.g. MAC tokens(draft-ietf-oauth-v2-http-mac-03.txt) Bearer (RFC 6750): tokens that any party in possession can use in any waythat other parties in possession can• False friend: bearer tokens (help to integrate by simplifying clients) vs.bearer grants (JWT/SAML 2 bearer, provide STS-style exchanges)© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  32. 32. Generalizations – IAM StylesEnterprise vs. Consumer IAM▶ Main IAM styles: EIAM – IAM for enterprise users (you@work):• Resources and identity records owned by legal entities• Representatives make decisions for resource pools and groups of users CIAM – IAM for consumer users (you@Facebook/Google/Twitter...):• Resources and identity records owned by individual users• Individuals make decisions for themselves▶ Especially authorization is fundamentally different for these IAM styles e.g. Different responsibilities• Administrator-managed vs. user-managed authorization Different state engines• First-policy-then-decision-requests vs. first-decision-requests-then-policy OAuth is rooted in the CIAM camp and is somewhat colonialistic:- 3-party exchanges are CIAM-style - they depend on explicit user consent- 2-party, STS-style exchanges (e.g. JWT/SAML 2 bearer) shift OAuthtowards EIAM territory© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  33. 33. Conclusions▶ The coincidence of Web APIs and consumer users provides use cases thatchange the game for: IT-security: new suite of Web security means - OAuth, JOSE… IAM: new tricks for user authorization and authentication, SSO in the Web▶ OAuth and OIDC are already in large-scale production use Meanwhile their development is ongoing▶ IAM key learning: a continental divide exists between EIAM and CIAM Mantra: don’t use EIAM hammers for CIAM nails and vice versa▶ Beware of voodoo discussions: Phantom pain: adding bearer tokens to OAuth is bad security-wise - there isno ‘standard meter’ in IT-security  not true Real pain: OAuth extensions e.g. STS-style exchanges, OIDC turn a special-purpose CIAM tool into a Swiss-knife for many things – {authz, authn},{user, app authn}, {CIAM, EIAM}  confusion is omnipresent▶ Keys towards mastership: Learn from implementing rather than reading – fuzzy texts around Simple things are to be achieved – always keep this in mind© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  34. 34. Author▶ Dr. Oliver Pfaff, oliver.pfaff@ic-consult.com© iC Consult GmbH 2013 - Dr. Oliver Pfaff
  35. 35. AbbreviationsACS Access Control ServiceAJAX Asynchronous JavaScript And XMLAPI Application Programming InterfaceAuthn AuthenticationAuthz AuthorizationCIAM IAM for Consumer usersDIY Do It YourselfEIAM IAM for Enterprise usersHTML HyperText Markup LanguageHTTP HyperText Transfer ProtocolIAM Identity and Access ManagementID IDentityIdM Identity ManagementIdP Identity ProviderJOSE JavaScript Object Signing andEncryptionJSON JavaScript Object NotationJWT JSON Web TokenOAuth Open AuthorizationOIDC OpenID ConnectOIDF OpenID FoundationPoP Proof-of-PossessionREST REpresentational State Transfer© iC Consult GmbH 2013 - Dr. Oliver PfaffSAML Security Assertion Markup Languagesaml: SAML assertion syntax namespace prefixsamlp: SAML protocol syntax namespace prefixSSO Single-Sign-OnSTS Security Token ServiceUI User InterfaceXML eXtensible Markup Language
  36. 36. Further Information▶ Bertocci, Vittorio: OAuth 2.0 and Sign-In. Blog 2013▶ Bray, Tim: Verifying Back-End Calls from Android Apps. Blog 2013▶ Bray, Tim: On ID Tokens. Blog 2013▶ Class, Gus: Using the one-time-code flow with Google+ Sign-in. Blog 2013▶ Jones, Mike: The Emerging JSON-Based Identity Protocol Suite. Paper - W3CWorkshop on Identity in the Browser 2011▶ Jones, Mike: OpenID Connect Update. Presentation - OpenID Workshop,European Identity Conference 2013▶ Kiani, Khash: OAuth-Securing the Insecure. Presentation 2011▶ Madsen, Paul: Mobile Native App-OAuth Decision Framework. Presentation 2011▶ N.N.: OAuth 2 for Native Apps. Wiki 2011▶ Richer, Justin: Auth* in the Extended Enterprise. Presentation - MIT Legal Hack-A-Thon 2013▶ Yegge, Steve: Steveys Google Platforms Rant. Posting 2011© iC Consult GmbH 2013 - Dr. Oliver Pfaff

×