Mais conteúdo relacionado Semelhante a OAuth Base Camp (20) Mais de Oliver Pfaff (15) OAuth Base Camp1. OAuth Base Camp
Lecture, Karlsruhe Institute of Technology, 2013-05-22
Dr. Oliver Pfaff
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
2. Preface
IT-Security - A Jigsaw Puzzle with Many Pieces
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
Authorization
▶ Today’s focus: authorization
For individually owned Web
resources
Discretionally managed by
their resource owners
▶ The discussed mechanism
addresses a key use case
It needs to be combined with
other security mechanisms
to deliver sound solutions -
engineered security
It needs to be implemented
with care to avoid eventual
breaches – secure engineering
Single-
Sign-On
Infrastructure
Authenticity
Key
management
Threats/Risks
Confidentiality
User/entity
authentication
Coding
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. User Authorization
Considered 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 Pfaff
You
Application
Your resources
Web container
HTTP
HTML
HTML
Web
browser
Your
user agent
Your service provider
Application
Web container
HTML
HTTP
Third-party provider
,JSON,XML
5. User Authorization
Relevance 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 your
assets – 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 get
exhausted quickly
Fundamentally important
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
6. User Authorization
Coverage 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 authn
themselves as end-users)
• Assign service provider credentials to them (which authn end-users
themselves and call as super-users)
IAM: use enterprise authorization approaches
• Utilize long-lived authorization policy objects established a-priori and
managed out-of-band (from the browsing sessions of users)
IT-security and IAM mechanisms as known/established until mid of last decade
not do the desired trick
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
7. User Authorization
How 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/glove
compartments, limits speed…
▶ Useful when trusting (discretionary powers) an attendant (third-party) to
park (limited use) the own car (resource)
▶ A Web-equivalent to valet parking keys would help: means that allow owners
of Web resources to delegate resource access to third-parties
in discretionary fashion
and a constrained way (time, functional scope…)
8. OAuth
Overview
▶ OAuth defines a resource authorization protocol that allows resource owners to
delegate resource access rights to third-parties in a discretionary fashion with
a limited functionality, for a limited time
▶ The OAuth specifications are developed by the IETF User Authorization
Protocol (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 version
2.0 by default (predecessor: The OAuth 1.0 Protocol RFC 5849, 2010)
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
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 owners
to delegate access rights dynamically and in-band (with their browsing sessions)
▶ and in 1 diagram:
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
Resource
owner
Resource
provider
Resource
consumer
3. Present user authz
1. Request user authz
2. Establish user authz
10. OAuth
The First Trick – User-Managed Authorization
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
OAuth-protected
resource endpoint
Resource
owner
Resource consumer
Resource providerAuthorization server
Post/Get/
Put/Delete with
access_token
200 OK with
<Resource>
Resource
client
30x Redirect with
code (URL query param)
Bold: objects/endpoints specified by OAuth
User authn
and consent
dialogues
: exchanges specified by OAuth
Authorization
endpoint
30x Redirect
with scope
(URL query param)
Redirection
endpoint
Token
endpoint
Post with client
creds, code (application/
x-www-form-urlencoded)
200 OK with
access_token
(application/json)
Token
client
11. OAuth
A 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 distributed
systems (attention: this refers to the native authorization code grant shown
above; things gets more subtle with OAuth extensions and additional grants)
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
12. OAuth
Core Abstractions
▶ Authorization grants: credentials that refer to resource owner’s authorization
and 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. OAuth
Extension Points
▶ Authorization grants: new grants e.g. JWT/SAML 2.0 bearer assertions defined
by 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 revocation
purposes 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 user
authentication 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. OAuth
Revocation
▶ 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 the
revocation 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 the
revocation 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 provide
Web 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. OAuth
Adoption
▶ 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. Demonstration
Accessing 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. 302 Found
HTTP GetHTTP PostHTTP Get
Demonstration
Web APIs that Will Be Called
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
Web
browser
Google
Token
endpoint
Authorization
endpoint
OAuth-protected
UserInfo endpoint
https://accounts.google.com/
o/oauth2/auth
https://www.googleapis.com/
oauth2/v1/userinfo
https://accounts.google.com/
o/oauth2/token
Authorization server
GoogleConnectServlet
UserInfo
ServiceClient
OAuthToken
ServiceClient
Redirection
endpoint
18. Demonstration
Implementation Remark
▶ To keep the code compact, the same servlet class is used to implement:
OAuth redirection endpoint: respond to subsequent requests from user
agents – 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. Demonstration
Important 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. Demonstration
Ditto for Facebook
▶ User-facing links:
Manage granted authorizations:
http://www.facebook.com/settings?tab=notifications§ion=application_not
ification
▶ 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. Key Observation
Complexity 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 body
parameter along with client id/secret (client authentication). OAuth token
received in response body (form-factor: JSON)
Authorization exchange: client id and scopes sent and authorization code
received 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 complexity
unevenly. This is a feature as it helps developers to integrate
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
22. Key Observation
Is 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. Generalizations – User Authentication
OpenID 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 about
the 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 a
new protocol for user authentication in distributed systems
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
24. Server-side transfer of state
Generalizations – User Authentication
The Second Trick: Server-Side SSO
© iC Consult GmbH 2013 - Dr. Oliver Pfaff© iC Consult GmbH 2013 - Dr. Oliver Pfaff
Web
browser
Authorization server
Get with
access_token
200 OK with30x Redirect with
code
User authn
and consent
dialogues
Authorization
endpoint
30x Redirect
with scope
Redirection
endpoint
Token
endpoint
Post with client
creds, code
200 OK with
access_token
Token
client
Identity consumer
Identity provider
Get inputs by tokenGet inputs by code
Bold: objects/endpoints specified by OIDC : exchanges specified by OIDC
,
id_token
UserInfo
(application/json)
OAuth-protected
UserInfo endpoint
UserInfo
client
and
value openid
25. Generalizations – User Authentication
Abstractions 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 objects
o 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 objects
o Based on JWT
o 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. Generalizations – User Authentication
Classifying OpenID Connect
▶ OIDC is a user authentication protocol based on OAuth – others that inherit
from OAuth are also feasible. Common recipe:
Expose a Web API that provides authenticated information about the current
user
Protect this Web API by means of OAuth
▶ This creates the problem of telling OIDC apart from other OAuth-based user
authentication protocols
▶ A protocol for federated IdM can be called OIDC iff it
utilizes OAuth 2.0 (RFC 6749) with bearer tokens (RFC 6750) according
the authorization code or implicit grants
presents the value openid in the OAuth scope parameter of its OAuth
authorization request messages
presents OIDC ID Token objects in either the OAuth authorization (implicit
grant) or the OAuth token response messages (code grant)
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
27. Generalizations – User Authentication
Examples
▶ Login with Facebook: OAuth-based user authentication protocol, not OIDC
Authorization exchange: no support of the value openid in the OAuth scope
parameter (cf. Permissions for supported scope values)
Token exchange: conducted via HTTP GET, no JSON response, no ID Token
objects provided
▶ Login with Google: OIDC
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
28. Client-sidetransferofstate
Generalizations – App Authentication
The Third Trick: Client-Side SSO
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
OAuth-protected
resource endpoint
e.g. GMail
Mobile
browser
Resource providerAuthorization server
Authorization
endpoint
Token
endpoint
Mobile device
Mobile
app
200 OK
Feed
(text/xml)
Post/Get/Put/Delete with access_token
User authn
and consent
dialogues
30x Redirects with
scope, code
Some
mechanism to
pass OAuth
creds
29. Generalizations – App Authentication
Obstacles 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 mobile
apps and providing SSO experience to them does not yet exist
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
30. Generalizations – Grant Types
OAuth Token Acquisition
▶ RFC 6749:
Authorization code: 3-party token acquisition with authorization codes
based on explicit user authorization for confidential clients (Web applications)
Implicit: 3-party token acquisition based on explicit user authorization for
public clients (AJAX clients, mobile apps)
Resource owner password credentials: 2-party token acquisition based on
user credentials without explicit user authorization (for migration purposes)
Client credentials: 2-party token acquisition based on client credentials
without explicit user authorization
Refresh token: 2-party token acquisition based on refresh tokens without
explicit user authorization
▶ Bearer profiles (IETF oauth WG drafts):
JWT/SAML 2 bearer: 2-party token acquisition based on JWT/SAML 2.0
bearer assertions (‘bearer grants’) without explicit user authorization
▶ Proprietary extension grants e.g.:
Google+ one-time-code: achieves the effects of the authorization code and
implicit grants in a single flow
Microsoft ACS bearer types: predecessors of JWT/SAML 2 bearer
…
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
31. Generalizations – Kinds of Tokens
Token Zoo
▶ Purposes:
Authz purposes: access tokens, refresh tokens (RFC 6749) - tokens with
defined purpose but undefined contents – implementations define contents
Authn purposes: ID tokens (OIDC) - tokens with defined purpose and
contents – claims about authentication event
▶ Types:
Opaque: tokens with contents that are opaque to token consumers (resource
endpoints) - coupling them to token producers
Self-contained: tokens with contents that can be processed by token
consumers - 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 way
that 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. Generalizations – IAM Styles
Enterprise 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 OAuth
towards EIAM territory
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
33. Conclusions
▶ The coincidence of Web APIs and consumer users provides use cases that
change 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 is
no ‘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. Author
▶ Dr. Oliver Pfaff, oliver.pfaff@ic-consult.com
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
35. Abbreviations
ACS Access Control Service
AJAX Asynchronous JavaScript And XML
API Application Programming Interface
Authn Authentication
Authz Authorization
CIAM IAM for Consumer users
DIY Do It Yourself
EIAM IAM for Enterprise users
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IAM Identity and Access Management
ID IDentity
IdM Identity Management
IdP Identity Provider
JOSE JavaScript Object Signing and
Encryption
JSON JavaScript Object Notation
JWT JSON Web Token
OAuth Open Authorization
OIDC OpenID Connect
OIDF OpenID Foundation
PoP Proof-of-Possession
REST REpresentational State Transfer
© iC Consult GmbH 2013 - Dr. Oliver Pfaff
SAML Security Assertion Markup Language
saml: SAML assertion syntax namespace prefix
samlp: SAML protocol syntax namespace prefix
SSO Single-Sign-On
STS Security Token Service
UI User Interface
XML eXtensible Markup Language
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 - W3C
Workshop 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: Stevey's Google Platforms Rant. Posting 2011
© iC Consult GmbH 2013 - Dr. Oliver Pfaff