Thread Safe

IETF OAuth WG rechartered

2012-05-15T14:09:00.001-04:00

The OAuth Working Group at the IETF has been rechartered.

These are the new Goals and Milestones

Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as aworking group item
Done Submit 'HTTP Authentication: MAC Authentication' as a working group item
Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard
Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard

May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard
May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard
May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC

Aug. 2012 Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token]

Nov. 2012 Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]

Dec. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard

Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC [Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]

Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]

John B.

@ve7jtb

JOSE v2 specs now available for your enjoyment

2012-05-12T21:47:00.001-04:00

Mike Jones and friends have published updated versions of the IETF JOSE specs.

Yes my affiliation on them is now Ping Identity. The change will not impact my involvement with JOSE, openID Connect, SAML or other specs that I hope to work on.

New -02 versions of the JSON Object Signing and Encryption (JOSE) specifications are now available that incorporate working decisions made since the previous versions, including decisions made at IETF 83 in Paris and in follow-up discussions on the working group list. The drafts contain numerous clarifications, refinements, and editorial improvements. They are:

· JSON Web Signature (JWS) – Digital signature/HMAC specification

· JSON Web Encryption (JWE) – Encryption specification

· JSON Web Key (JWK) – Public key specification

· JSON Web Algorithms (JWA) – Algorithms and identifiers specification

These specifications are available at:

· http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02

· http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02

· http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02

· http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02

The document history entries (also in the specifications) are as follows:

http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02:

Clarified that it is an error when a kid value is included and no matching key is found.
Removed assumption that kid (key ID) can only refer to an asymmetric key.
Clarified that JWSs with duplicate Header Parameter Names MUST be rejected.
Clarified the relationship between typ header parameter values and MIME types.
Registered application/jws MIME type and "JWS" typ header parameter value.
Simplified JWK terminology to get replace the "JWK Key Object" and "JWK Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web Key Set (JWK Set)" and to eliminate potential confusion between single keys and sets of keys. As part of this change, the header parameter name for a public key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key).
Added suggestion on defining additional header parameters such as x5t#S256 in the future for certificate thumbprints using hash algorithms other than SHA-1.
Specify RFC 2818 server identity validation, rather than RFC 6125 (paralleling the same decision in the OAuth specs).
Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
Reformatted to give each header parameter its own section heading.

http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02:

When using AEAD algorithms (such as AES GCM), use the "additional authenticated data" parameter to provide integrity for the header, encrypted key, and ciphertext and use the resulting "authentication tag" value as the JWE Integrity Value.
Defined KDF output key sizes.
Generalized text to allow key agreement to be employed as an alternative to key wrapping or key encryption.
Changed compression algorithm from gzip to DEFLATE.
Clarified that it is an error when a kid value is included and no matching key is found.
Clarified that JWEs with duplicate Header Parameter Names MUST be rejected.
Clarified the relationship between typ header parameter values and MIME types.
Registered application/jwe MIME type and "JWE" typ header parameter value.
Simplified JWK terminology to get replace the "JWK Key Object" and "JWK Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web Key Set (JWK Set)" and to eliminate potential confusion between single keys and sets of keys. As part of this change, the header parameter name for a public key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key).
Added suggestion on defining additional header parameters such as x5t#S256 in the future for certificate thumbprints using hash algorithms other than SHA-1.
Specify RFC 2818 server identity validation, rather than RFC 6125 (paralleling the same decision in the OAuth specs).
Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
Reformatted to give each header parameter its own section heading.

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02:

Simplified JWK terminology to get replace the "JWK Key Object" and "JWK Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web Key Set (JWK Set)" and to eliminate potential confusion between single keys and sets of keys. As part of this change, the top-level member name for a set of keys was changed from jwk to keys.
Clarified that values with duplicate member names MUST be rejected.
Established JSON Web Key Set Parameters registry.
Explicitly listed non-goals in the introduction.
Moved algorithm-specific definitions from JWK to JWA.
Reformatted to give each member definition its own section heading.

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02:

For AES GCM, use the "additional authenticated data" parameter to provide integrity for the header, encrypted key, and ciphertext and use the resulting "authentication tag" value as the JWE Integrity Value.
Defined minimum required key sizes for algorithms without specified key sizes.
Defined KDF output key sizes.
Specified the use of PKCS #5 padding with AES-CBC.
Generalized text to allow key agreement to be employed as an alternative to key wrapping or key encryption.
Clarified that ECDH-ES is a key agreement algorithm.
Required implementation of AES-128-KW and AES-256-KW.
Removed the use of A128GCM and A256GCM for key wrapping.
Removed A512KW since it turns out that it's not a standard algorithm.
Clarified the relationship between typ header parameter values and MIME types.
Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
Established registries: JSON Web Signature and Encryption Header Parameters, JSON Web Signature and Encryption Algorithms, JSON Web Signature and Encryption "typ" Values, JSON Web Key Parameters, and JSON Web Key Algorithm Families.
Moved algorithm-specific definitions from JWK to JWA.
Reformatted to give each member definition its own section heading.

John B.

@ve7jtb

OpenID Connect Wins 2012 European Identity and Cloud Award

2012-04-18T20:18:00.000-03:00

Today at the European Identity and Cloud Conference it was announced that OpenID Connect has won the 2012 European Identity and Cloud Award for “Best Innovation / New Standard in Information Security”. The OpenID Foundation and the Connect working group members want to thank Kuppinger Cole for this prestigious award and their vote of confidence in the significance of OpenID Connect. The application presented by the OpenID Foundation that resulted in the award follows.

European Identity & Cloud Awards 2012

Project company:	OpenID Foundation
Award category:	Best Innovation / New Standard in Information Security

1) Name of the Standard

OpenID Connect

2) Brief description of the Standard

OpenID Connect is a simple JSON/REST-based interoperable identity protocol built on top of the OAuth 2.0 family of specifications. Its design philosophy is “make simple things simple and make complicated things possible”.

While OAuth 2.0 is a generic access authorization delegation protocol, thus enabling the transfer of arbitrary data, it does not define ways to authenticate users or communicate information about them. OpenID Connect provides a secure, flexible, and interoperable identity layer on top of OAuth 2.0 so that digital identities can be easily used across sites and applications. While enabling a default set of common claims about the user (such as name, e-mail address, and a user identifier enabling SSO) to be easily employed, OpenID Connect also enables participants to exchange any claims relevant to their application using simple JSON-based data structures.

As it is based in OAuth 2.0, OpenID Connect reaches beyond the Web. OpenID Connect brings identity interactions to “apps” and “native applications” on both smart phones and traditional computing devices, in addition to Web sites.

From a security perspective, OpenID Connect was built to be able to gracefully range from the low security levels typically employed for social networks to medium security levels needed for business applications to high security requirements needed for many government applications. OpenID Connect spans this wide range of applications by using JSON-based digital signature and encryption standards.

From a privacy perspective, OpenID Connect allows the selective sharing of attributes with user consent. It also enables the use of pairwise pseudonymous identifiers, thereby avoiding correlations as appropriate.

From a business perspective, OpenID Connect meets business needs for the use of claims from multiple Claims Providers in a single context (rather than a single Identity Provider being the source of all claims for any given interaction). It enables the use of Aggregated Claims, where signed claim values can be collected and passed on by OpenID Providers and the use of Distributed Claims, where claims are passed by reference, rather than by value, and dynamically retrieved by Relying Parties.

From a design perspective, OpenID Connect’s modular design enables flexible deployments. Implementations can use only the components they need, while still remaining interoperable. For instance, “Discovery” and “Dynamic Client Registration” can used in deployments where OpenID Providers can be chosen dynamically, whereas they aren’t needed if the site or application uses only a fixed set of OpenID Providers.

Unlike the previous version of OpenID, user identities can be e-mail addresses that people already have and know, rather than being URLs that most people have difficulty using.

3) Who is contributing to the standard?

OpenID Connect was developed in an OpenID Foundation working group. OpenID working groups are open to all free of charge who sign the IPR Contribution agreement. Contributors include a diverse international representation of industry and independent technology leaders: AOL, Deutsche Telecom, Facebook, Google, Microsoft, Mitre Corporation, mixi, Nomura Research Institute, PayPal, Salesforce, Yahoo! Japan, and others.

4) When is it expected to be finalized?

OpenID Connect is in the Implementer’s Draft review period. That stage is similar to the DIS (Draft International Standard) phase of the ISO process. The approval vote will complete on February 15, 2012. The OpenID Connect specifications are expected to be competed in the second half of 2012.

5) What are the key Identity management objectives?

- Interoperability

- Security

- Ease of deployment

- Flexibility

- Wide support of devices

- Enabling Claims Providers to be distinct from Identity Providers

6) Does the standard exceed key objectives?

Yes.

7) Are there live deployments?

Yes. e.g., Google, Gakunin (Japanese Universities Network), Nikkei Newspaper, etc.

Mature deployments are under way by working group participants.

8) Does the deployment touch customers/consumers/citizens? If so, what benefit(s) is the application delivering to customers/consumers/citizens?

- More secure and familiar online interactions

- Easier to use authentication and attribute sharing

9) Does the deployment successfully address one of more of the following identity issues? If so, please provide brief examples.

- Help prevent/reduce identity theft? Yes.

- Help address ease of use issues? Yes.

- Help meet regulatory requirement? Yes.

- Meet unique vertical market objectives? Yes.

10) Why should this standard win the European Identity/Cloud Award?

OpenID Connect is a significant advance in digital identity that:

a) is simple to build and deploy, being based upon existing JSON/REST standards,

b) spans both Web and native applications, including mobile “apps”,

c) has wide support from major cloud service providers, enterprise companies, and social networking companies,

d) helps combat identity theft by reducing the number of passwords in use,

e) enables new Web based services and expands existing online markets,

f) spurs global economic growth by enabling simple and secure exchange of verified attributes from multiple sources at Internet scale.

OpenID Connect is an important contribution to a safer, privacy protecting, and easy to use computing environment that spans the cloud, the Web, enterprises, and mobile applications and has broad industry backing. For these reasons, OpenID Connect merits the 2012 European Identity/Cloud Award.

John B.

@ve7jtb

Request by JSON ver.1.0 for OAuth 2.0 updated.

2012-04-15T05:17:00.001-03:00

Nat and I originally submitted this ID in 2010.

It was incorporated into openID Connect as the way to make authenticated requests to the Authorization server. This is necessary in some but not all use cases.

Recently a number of people have requested that Request by JSON become a general OAuth extension, and connect reference it to improve interoperability.

We have refreshed the ID to keep it alive and make some minor updates.

This came up after the OAuth rechartering discussion so I don't expect that it is anything the OAuth WG would take on in the near future.

Keeping it warm as an ID for people who are interested to work on and reference is probably the best option.

We would not want this to become a blocking factor for Connect final publication, but also have no problem with others using the same mechanism outside of connect.

If people are interested we can discuss it on the OAuth list as part of rechartering until they kick us off:)

John B.

OpenID Connect Technology Meeting, April 30, 2012

2012-04-07T13:33:00.000-03:00

Workgroup Meeting

Lunch is at noon and the meeting starts at 1pm.

Non Members are welcome to attend, but must be aware of the OIDF IPR policy.

Registration

John B.

@ve7jtb

OpenID Workshop at EIC

2012-04-07T12:49:00.000-03:00

On the morning of Tuesday Apr 17, The openID Foundation is holding a workshop at the European Identity Confrence in Munich.

You can attend even if you are not attending EIC.

This will cover OpenID Connect and Account Chooser activities.

John B.
@ve7jtb

Followup on OAuth / Facebook login vulnerability.

2012-04-06T20:04:00.001-03:00

I blogged about The problem with OAuth for Authentication and followed up with More on OAuth implicit flow application vulnerabilities.

It however appears that many sites using Facebook login, especially from apps are not understanding or taking the issue seriously.

There are popular social sites that effectively have no security!

Nov Matake @nov has filed issues with them but, without much action from most.

I am more of a theoretical guy these days rather than a programmer. I clearly see the flaw, but to help our developer friends understand Nov has produced an iPhone app to show the issue. The code is available ion Github.

Bad people are probably doing bad things with this exploit now.

My recommendation is that if you are relying on a OAuth implicit flow to authenticate applications or users, read the posts and contact us if you are unsure.

I could name the sites and create a big flap, but I don't think embarrassing people publicly is called for yet.

John B.
@ve7jtb

Preview of OpenID Connect Test Facility now open!

2012-03-21T12:38:00.000-03:00

Andreas Åkre Solberg and Roland Hedberg are happy to announce that today they are making a technology preview of the OpenID Connect Test Facility publicly available.

Here is a video demo of how it all works.

Start to test your OpenID Connect Provider right away!

This is an early preview of a pretty complex set of software, so we’re asking you to be patient, and please report any issues to us. You can do that by posting to the github issue tracker or respond to the openID Connect interop list.

Additional Resources:

John B
@ve7jtb

JSON Object Signing and Encryption (JOSE) Draft 01 & JSON Web Token (JWT) specification Draft 08

2012-03-12T22:05:00.000-03:00

New versions of the JSON Object Signing and Encryption (JOSE) specifications are now available that incorporate working group feedback since publication of the initial versions. They are:

JSON Web Signature (JWS) – Digital signature/HMAC specification
JSON Web Encryption (JWE) – Encryption specification
JSON Web Key (JWK) – Public key specification
JSON Web Algorithms (JWA) – Algorithms and identifiers specification

The most important changes are:

Added a separate integrity check for encryption algorithms without an integral integrity check.
Defined header parameters for including JWK public keys and X.509 certificate chains directly in the header.

See the Document History section in each specification for a more detailed list of changes.

Corresponding versions of the JSON Serialization specs, which use these JOSE drafts, are also available. Besides using JSON Serializations of the cryptographic results (rather than Compact Serializations using a series of base64url encoded values), these specifications also enable multiple digital signatures and/or HMACs to applied to the same message and enable the same plaintext to be encrypted to multiple recipients. They are:

JSON Web Signature JSON Serialization (JWS-JS)
JSON Web Encryption JSON Serialization (JWE-JS)

Draft 08 of the JSON Web Token (JWT) specification has been published. It uses the -01 versions of the JOSE specifications and also contains these changes:

Removed language that required that a JWT must have three parts. Now the number of parts is explicitly dependent upon the representation of the underlying JWS or JWE.
Moved the “alg”:“none” definition to the JWS spec.
Registered the application/jwt MIME Media Type.
Clarified that the order of the creation and validation steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.
Corrected the Magic Signatures and Simple Web Token (SWT) references.

These specifications are available at:

HTML formatted versions are available at:

John B.

@ve7jtb

A New Venn Of Access Control For The API Economy

2012-03-12T16:56:00.002-03:00

Up on the Forrester blogs, Eve Mailer has posted a new Venn diagram that compares OAuth, OpenID Connect, and UMA. A number of people contributed to the final form of this one, which we presented in a Google Tech Talk a couple of weeks back. Thanks to all of the following folks (listed in no particular order) for their feedback!

John B.

@ve7jtb

OpenID Connect Workshop at Paris IETF

2012-03-01T16:19:00.002-03:00

We are having a workshop on Sunday Mar 25, prior to IETF 83.

It will be in Room 243 at Le Palais des Congres de Paris

Workgroup members and other interested people are welcome to attend.

Registration is now open.

The easiest way to monitor progress on the OpenID Connect 1.0 Specification is to join the mailing list at http://lists.openid.net/mailman/listinfo/openid-specs-ab.

Please note that while anyone can join the mailing list as a read-only recipient, posting to the mailing list or actively contributing to the specification itself requires the submission of an IPR Agreement. More information is available at http://openid.net/intellectual-property. Make sure to specify the working group as “OpenID AB/Connect”, because this group is a merged working group and both names must be specified.

The working group specification repository is kept at http://svn.openid.net/repos/specifications/connect/1.0/ . In this repository, only approved sub-versions are committed. If you want to live on the edge, go to http://hg.openid.net/connect/ where we keep edit by edit commits. These edits make it into SVN once they are approved by the editors.

John B.

@ve7jtb

GoAway GoDaddy

2012-02-18T16:50:00.001-03:00

I have been annoyed by GoDaddy for a while, but they are cheep for registering Domain Names.

However there recent positions on SOPA and PIPA finally pushed me over the edge to moving all of my services from them.

I also had some domains other places. Looking at the situation I decided to do something I have thought about a number of times in the past.

I am now a Domain Reseller. Using the back end software from tucows in Toronto, I have set up a site and moved my own domains to it.

I know there are other people who probably want to move as well, but find the idea of becoming a registrar a bit more than they want to do for a couple of names.

Others are welcome to use my site wingaa.com if they are OK with having only a moderately evil Registrar.

My volume is low so I don't have the lowest prices, but I do provide a full DNS service that is extra many places. No I will not put advertising on your squatted web pages for you. Go someplace else for that.

If nothing else I feel better having more direct control over my own names.

At some point I may do some experimentation with adding other hosted identity services for domains. That was our plan at ooTao when I first looks at doing this years ago.

For the curious Wingaa means 'My name is...' in the Central Alaskan Yup'ik language.

It is a recycled name that Andy Dale and I had as a part of ooTao back in the day.

John B.

@ve7jtb

OpenID Connect Interop in Progress

2012-02-18T13:45:00.000-03:00

The Third OpenID Connect Interop is currently under way – this time based upon approved Implementer’s Drafts. Currently 7 implementations are being tested, with I believe more to be added. The interop is designed to enable people to test the implementations they’ve built against other implementations and verify that specific features that they’ve built are working correctly. This has several benefits: it helps debug implementations, it helps debug the specifications, and it results in greater interoperability among OpenID Connect implementations.

As background, like the other OSIS interops, the OpenID Connect interop is an opportunity for implementers to try their code against one another’s in a systematic way. It is not a conformance test; participants do not “pass” or “fail”. There is no requirement that you must support particular features to participate or that you must participate in all aspects of the interop.

If you’d like to participate in the interop, join the OpenID Connect Interop mailing list and send us a note there saying who your interop contact person will be, the name of your organization (can be an individual), the name of your implementation (can be your name), and a list of the online testing endpoints for your implementation. Testing is performed online on your schedule, with results recorded on the interop wiki. That being said, an in-person meeting of interop participants will also be held on Friday, March 2 in San Francisco (the week of RSA) for those who are able to attend.

John B.
@ve7jtb

OpenID Connect Approved as Implementers Draft

2012-02-16T11:33:00.000-03:00

Thank you to everyone who voted.

The approval of the specifications as an implementers draft is an important step on the road to a final specification.

This serves to lock in the current IPR contributions by all the contributors. This gives initial implementers confidence to start developing code without worrying about IPR issues.

The Vote results were:

Approve (86 votes)
Disapprove (1 vote)
Abstain (2 votes)

Total Votes: 91

We are now entering a phase of development and interop testing.

There are currently 7 participants testing code and deployments.

John B.
@ve7jtb

More on OAuth implicit flow application vulnerabilities.

2012-02-10T18:01:00.000-03:00

My blogpost last week The problem with OAuth for Authentication has gotten the attention of some of the apps developers.

Nov Matake @nov has filed this issue with the Apple Security Team regarding iOS applications.

There is a good articles in Japanese at OAuth.jp Damage caused by the Implicit flow login, and The problem with the iOS SDK. Both posts look at current deployed applications and SDK vulnerability to the sort of attack I described.

I will attempt a rough translation for those of you who don't read Japanese.

Premise:

There is a gaming platform that supports OAuth 2 for authentication.
There is an attacker who runs a fortune-telling game on a mobile platform.
Legitimate games are operated on the same platform.

Assumption:

The game application is not otherwise vulnerable to XSS, CSRF, or session hijacking.
Both applications are using Oauth 2.0 implicit flow for authentication.

Scenario:

The attacker running the fortune-telling game gets the user to login.
Attacker gets access token for Social Network Graph API
The attacker then uses that access_token to log into the legitimate game by modifying the URI fragment to insert the stolen access_token into the response.
The attacker now has complete access to the users account on the legitimate game.

This scenario is not limited to gains but applies to many mobile applications using OAuth for authentication.

The reason this works is that the OAuth client has no way in OAuth to tell what client the token was issued to. (In openID connect we use a structured id_token with an audience to protect against this)

If the OAuth platform is Facebook there is a way developers can protect themselves. They have a token introspection API that returns your application's client ID.

End attempt at translation:)

Sone comments by me.

This is a example Facebook token introspection request.

Example:

https://graph.facebook.com/app?access_token=[The Access Token]

Response:

{
"id": "314251861954810",
"name": "jbradley",
"link": "https://www.facebook.com/apps/application.php?id=314251861954810",
"canvas_name": "thread-safe",
"namespace": "thread-safe",
"icon_url": "https://s-static.ak.facebook.com/rsrc.php/v1/yT/r/4QVMqOjUhcd.gif",
"logo_url": "https://s-static.ak.facebook.com/rsrc.php/v1/y_/r/9myDd8iyu0B.gif",
"daily_active_users": "1",
"weekly_active_users": "1",
"monthly_active_users": "1"
}

The client checks that the value of id is it's client id and you know the token was intended for you.

The connect id_token puts the client_id in the aud claim so that the client has it without doing an extra round trip.

Example decoded id_token.

TTP/1.1 200 OKContent-Type: application/json
{ "iss": "http://server.example.com", "user_id": "248289761001", "aud": "314251861954810", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970}

Facebook also has signed_request that can also protect agains this.

My point is that OAuth 2.0 can be used safely, but it is designed as an authorization protocol. It needs some extension to be used for authentication. The problem is that explaining things like id_tokens or the Facebook token introspection endpoint makes it look more complicated, so people have not been doing it and it seems to have caused some vulnerabilities in applications and frameworks.

John Bradley

@ve7jtb

Voting open for openID Connect Implementers Draft

2012-02-08T16:42:00.003-03:00

After a 45 Review period, voting is now open for the OpenID Connect Implementer's Draft .

Voting is open to all openID Foundation Members.

Please register your vote before 2012-02-15.

Link:
https://openid.net/foundation/members/polls/62

Title:
OpenID Connect Implementer's Draft

Description:
The OpenID AB+Connect Working Group recommends approval of the following specifications as OpenID Implementer’s Drafts:

Basic Client Profile – Simple self-contained specification for a web-based Relying Party. (This spec contains a subset of the information in Messages and Standard.)
Discovery – Defines how user and provider endpoints can be dynamically discovered.
Dynamic Registration – Defines how clients can dynamically register with OpenID Providers.
Messages – Defines all the messages that are used in OpenID Connect. (These messages are used by the Standard binding.)
Standard – Complete HTTP binding of the Messages, for both Relying Parties and OpenID Providers.
Multiple Response Type Encoding – Registers OAuth 2.0 response_type values used by OpenID Connect.

An Implementer’s Draft is a stable version of a specification providing intellectual property protections to implementers of the specification.

A description of OpenID Connect can be found at http://openid.net/connect/. The working group page ishttp://openid.net/wg/connect/.

Available Choices:

Approve
Disapprove
Abstain

Thank you for your participation!

John Bradley

@VE7JTB

Designing a Single Sign-on system using OAuth 2.0

2012-02-04T20:52:00.001-03:00

Lets first consider what a Single Sign-on System is.

A SSO system provides access control for multiple independent systems based on a single login.

This is typically what openID 2.0 is used for and in many cases Facebook Connect or Twitter on the social web.

Lets use a real example, one site I use a lot is tripit.com. They are a excellent example of how a website can take advantage of both web and mobile apps using single sign on and OAuth.

I login at tripit on the web by clicking a google button to login using openID 2.0 with OAuth 1.1 or a Facebook button to Login with OAuth 2.0 and Facebook's Graph API extensions.

I never provide a username and password to tripit they let me in based on a statement from a third party that I am logged in to that third party as some particular user.

This saves me from having to remember yet another username and password. However if that was all there was too it probably they would just ask for a username (email) and password like most other sites.

However they are taking advantage of the fact that if I use a credential from Facebook or Google they have additional API (Application Programming Interface) and information that can be linked to my tripit account to make there web site better integrated into my social web activity.

At Facebook I can grant tripit access to push trip information into my activity stream, and look at my friends list, so that they can notify me when one of my friends joins tripit,

At Google I can grant tripit access to scan my incoming email for travel itineraries emailed to me when I make a reservation. They can also get access to my portable contacts endpoint and other information if I grant them access.

All of this additional information that I may grant them access to is what OAuth is used for.

Having worked on protocols like Info Card for Authentication (Not SSO) to websites is that the lack of access to rich API is what stopped Websites like Tripit from being interested in them. As an aside I think Mozilla's Browser-ID has the same flaw of focusing only on Authentication. It just is not enough any more.

So for the SSO system I want to design it needs to enable OAuth 2.0 access to arbitrary API. I don't want to stifle innovation by presupposing that I know every possible API that is ever going to be invented on the Internet for the rest of time. The API I may want to give a RP access to might be just a stream of my favourite songs, or photos etc.

The API like SalesForce.com and most others already have access tokens that they use. I don't want to start imposing a particular format for access tokens if I am going to be a good citizen and design something that works with existing OAuth protected API.

The API will have permissions not related to my interactive session with the web site. In the case of tripit when I use my iPhone app to update something in my account, I expect them to be able to push that to my Facebook activity stream without me logging in again with a traditional web browser session for them to get access. (This was referred to as offline access permission by Facebook, it is now the default.) While a login session requires the users presence in some way the OAuth activity the user authorizes may be longer lived than the session and require the use of OAuth refresh tokens to control access.

So as a core design principal I am going to create a SSO profile that works with OAuth 2.0 and interferes as little as possible with access tokens and existing endpoints. I hope that sounds reasonable.

Next we need to consider what we need for the SSO portion of the protocol.

We defiantly need to know some things (at least in my opinion):

Who is doing the Authentication of the user and making the assertion about the user.
Who is the user, some sort of persistent over time user identifier.
Who is the assertion being made to. This prevents replay of assertions intended for other clients.
How long is this assertion good for before the client needs to check if the user is still authenticated.
A method to link the browser session to the assertion and detect replay attempts.

Without those things the Relying Party (RP) or client in OAuth speak can't do a proper job of determining if they can trust the assertion to let the user in.

There are some optional things that not every RP is going to want, but some RP are going to really need if they are going to protect themselves and you from hacking.

Indication of the Authentication context or circumstances. (Were they identity proofed, and did they login with a second factor like a SMS message to there registered phone)
When did they last do an interactive login(not cookie) if it was 6 days ago the site may elect to have the user go back to there Single Sign-on Provider and re-authenticate in some way to show that they are still the one using the computer.

If the RP can get that information we are doing quite well.

The next thing we need to figure out is how to ask the SSO/Authorization Provider for the SSO things. For Authorization we have scopes, though not super sophisticated they provide a way to say give me authorization to access some stuff at some endpoint.

So lets make a scope called authentication-information (I know it is a bit long, this is an example lighten up) , we define it to be a request to make available a set of claims about the authentication event at a new OAuth protected endpoint we create. Call the new endpoint auth_info_endpoint.

This keeps us from stepping on other OAuth protected resources. We can pass multiple scopes to the Authorization endpoint in our authorization request so whatever our original scopes were for our protected resource will still work.

To make this work we need to get two access tokens back from the Authorization endpoint. One that is for our original protected resource that we are not interfering with, and one for the auth_info_endpoint.

Fortunately OAuth allows us to define new response_type that can return multiple tokens. Currently in preparation for the completion of OAuth and the opening of the response_type registry Facebook and Google authors put together a Multiple Response Type Encoding Practices registration proposal that we can use. Facebook and Google have already implemented versions of it as part of there OAuth 2 deployments.

That document defines an additional token that is returned in a parameter called id_token. The requirement is that token provides an assertion about the identity of the resource owner. Remember there is nothing in the actual OAuth 2.0 spec that requires the access_token to in any way identify the resource owner, the resource owner might be someone entirely different than the one granting the client access.

The nice thing about the new endpoint and token is that we can restrict it so that the resource owner of the endpoint is the person who is being authenticated.

So lets go through this flow I am proposing.

The RP(client) makes a request via redirect through the users browser and sets a session cookie in the browser to track the authentication/authorization request.

They calculate a hash of a session cookie to use in the request.

Example SSO/Authorization request.
https://server.example.com/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&scope=authentication-information%20http://www-opensocial.googleusercontent.com/api/people
&state=af0ifjsldkj
&nonce=af0ifjsldkj

I am sending the scope for the authentication information and one for Google's portable contacts endpoint as an example.

The hash we calculated is being sent in both state and nonce that is because some clients are already putting other information in the OAuth state parameter. It may be duplication but I am trying to avoid stepping on existing OAuth elements.

Lets look at the response:

HTTP/1.1 302 Found
Location: https://client.example.com/cb#
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZ
XJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0c
DpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1
G3liaTNOrfaeWYjuRCEPNXVtaazNQ
&state=af0ifjsldkj

We get back three fragment encoded parameters:

code, for use at the token endpoint to get access and refresh tokens for the portable contacts API.
id_token,an access token for the auth_info_endpoint.
state, the value we sent in our request to look up who this response is coming from.

By looking up state we can find the for the SSO/Authorization server(this could be configured out of band as part of client_id and client_secret provisioning).

We make a Bearer token request to the auth_info_endpoint.

POST /auth_info_endpoint HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZX
J2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0cD
pcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1G
3liaTNOrfaeWYjuRCEPNXVtaazNQ

The response would be a JSON object for simplicity:

HTTP/1.1 200 OK
Content-Type: application/json

{
"iss": "https://server.example.com",
"user_id": "248289761001",
"aud": "s6BhdRkqt3",
"nonce": "af0ifjsldkj",
"exp": 1311281970
}

We know have an assertion tied to the browser session via nonce, from a endpoint known to be under the control of the resource owner.

It contains:

iss, The identifier for the SSO/Authorization service.
user_id, An identifier that is unique for that user in the scope of the SSO/Authorization service.
aud, The client_id from the authentication request. (if it doesn't match the client's client_id, the token is being replayed.)
nonce, To bind the assertion to the browser session and prevent replay.
exp, The expired time of the assertion. The RP should request a new id_token from the SSO/Authorization service before this expires.

You may ask how the SSO/Authorization service knows the correct RP/Client is getting the id_token.

The RP/Client registers it's redirect_uri as part of getting it's client_id. If both endpoints are TLS protected then this is no less secure than the SAML post binding FICAM has approved at LoA 3 without encrypting the token end to end.

The client has the code that it can use at the SSO/Authorization service's token_endpoint.

All of the regular API activity at the portable contacts endpoint can occur with OAuth 2.0 exactly the way it would have before we introduced the SSO elements.

I should point out that Facebook is using a response_type called signed_request rather than id_token, they also include code inside the token, so that you don't need to ask for it separately. If you do ask for code they do send it back as a parameter.

As an optimization the client can directly decode and verify both id_token and signed_request directly without making a second https request to the SSO/Authorization service.

If this sounds like a reasonable proposal for a OAuth extension then please have a look at OpenID Connect Basic Client, it is almost the same as what I have discussed here but adds a user-info endpoint to get additional user profile information.

OpenID Connect has a check_id endpoint that works as I have decried taking the id_token for access. Facebook doesn't currently have a introspection endpoint for signed_request though it has been talked about. There argument is that the client should just validate the signature and use the token.

Both id_token and signed_request have a HMAC-SHA256 integrity check generated with the client_password as the secret by default. That makes it easy for the RP/client to verify.

However as the client can also create tokens with an equivalent HMAC that prevents them from being trustable by anything other than a token introspection endpoint like the openID Connect check_id endpoint. In openID 2.0 the association endpoint provided the same introspection for clients unable to verify assertions themselves.

I hope this gives you another perspective on how openID Connect and other OAuth based SSO protocols can work.

John B.
@ve7jtb

eBay's project Oreo, would you like milk with your openID?

2012-02-02T17:25:00.000-03:00

eBay has made available a technology preview of their Project Oreo.

OREO is eBay's implementation of the OpenID Connect Standard. OREO will become open source in the near future and developers can use it to implement their own OpenID Compliant service.

They also have a demo RP setup to use there test IdP at:

https://openidconnect.ebay.com/oreo/start.jsp

This is just one of the test systems people are getting ready to test at the upcoming openID Connect interop on March 3rd.

John B.
@ve7jtb

Why we need a id_token in openID Connect & Facebook Connect

2012-02-01T20:19:00.003-03:00

Early in the requirements phase of openID Connect design one of the inputs was that websites need fast login. Users apparently abandon the login process if it looks like there browser redirect is taking too long.

Facebook presented timing information that to be widely accepted openID connect would need to deliver a verifiable user_id as part of the initial response. That way the web site can verify the user_id and present a welcome screen while it is pulling other information in the back channel.

In order to do the same thing it turned out that Facebook is doing some undocumented things in the client code it delivers to web sites.

They are using a OAuth 2.0 response_type called signed_request. This returns a signed JSON object in the URI fragment.

An example OAuth request:

https://www.facebook.com/dialog/oauth?
client_id=314251861954810
&redirect_uri=http%3A%2F%2Ftest-id.org/
&response_type=signed-request

The Response:

http://test-id.org/#signed_request=tr0ZF2hnsqGuL3pKxUTZZYL6pCK4VKplKhop7BnIup0.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUURzSFBLcEVwRmpWb0pnbFZqcS00dWk5MThwUWRRVTdPRjZZMTFXajZxOUFnWUdhYUhxU1VlcWNpX0VyZHRTakJramNzc2VjcnRvQzRyU3l2TVdVR0NidXpXV2dLeFNCSkJSeHBRbmxrMTB5Ty1TN3hWc2Z0MUwtVEFxNWplbThiOWlKRW1RaFhsVW1OM0hTNWR4TFJLc3hrajJCT3ZDa1YyQ1ZsYkpwOGRMU1V2TWtLb1ZnbGtZRnQ1N0k5eE5kZnciLCJpc3N1ZWRfYXQiOjEzMjgxMjc4NzAsInVzZXJfaWQiOiI2MTQzNDU0NDkifQ

The base64 decoded signed_request:

{
"algorithm":"HMAC-SHA256","code":"AQDsHPKpEpFjVoJglVjq-4ui918pQdQU7OF6Y11Wj6q9AgYGaaHqSUeqci_ErdtSjBkjcssecrtoC4rSyvMWUGCbuzWWgKxSBJBRxpQnlk10yO-S7xVsft1L[...]",
"issued_at":1328127870,
"user_id":"614345449"
}

Everything after the period in the token is base64 decoded then you perform a HMAC of the base64 encoded version using algorithm and your client password. The result is the value encoded before the period.

The Facebook Java Script verifies the token and sets the user_id as a cookie in the users browser. It also extracts the code and gives it to the Web server to exchange at the token endpoint for a access_token.

Token Endpoint Request:

https://graph.facebook.com/oauth/access_token?client_id=314251861954810&redirect_uri=http%3A%2F%2Ftest-id.org/&client_secret=b80c53ef7fcb1363a3ba9a&code=AQDfxYh0xSroZZgpk23rYsCOSrCQV7B3M7ABNHw[...]

Token Endpoint Response:

access_token=AAEdz3aaEPoBALt9n4sDni6inzlZzVFlfleyFtloUJKVC2fdLlO0xvdeG9
&expires=5178704

Facebook is also supporting multiple response types such as:

https://www.facebook.com/dialog/oauth?client_id=314251861954810&redirect_uri=http%3A%2F%2Ftest-id.org/&response_type=signed_request%20token

Return both the access_token and signed_request in the URI fragment.

We looked at Facebook's solution, but felt it had a number pluses and minuses.

The Good.

It meets the design goal of quick user_id credential delivery to the web client without a extra round trip.

The signed_request provides a form of implicit audience restriction based on the symmetric signature to prevent replay of tokens at different endpoints. I discuss this attack in The problem with OAuth for Authentication.

The Bad.

The client needs to implement crypto support to use the signed_request token.

The client requires two additional network round trips to get the profile information. The reason for that is the signed_request contains code and not token. This is because the signed_request token is normally stored in the browser as a cookie. If the access token were in it there would be a possibility of it leaking. Leaking a long term access token is much worse than a short term session identifier. This necessitates exchanging code for the access_token, and then the access_token for the user information.

With code inside signed_request you wind up storing a much larger cookie than required, code is very short lived keeping it around in the cookie is not useful.

The format Facebook is using for signing is not a standard it doesn't support signing generic JSON, and it has no support for encryption. We thought using a IETF standard would be good practice and help with library support.

The solution.

We decided to modify signed request token by:

Removing the code claim from inside the token.
Add a Audience claim aud that has the client id the token was issued for. (needed for asymmetric signatures)
Add a nonce to prevent replay attacks.
Add a Issuer iss claim, this is important once you have more than one provider.
Use the multi token response type to allow the client to ask for any combination of tokens.
Provide a convenience endpoint to validate the signed token.
Use a standards based JSON crypto library JOSE and token format JWT.
Rename the token to id_token to be clearer on it's purpose.

We think this is a cleaner design. The id_token is now small and can be used by a session management extension or as a cookie. It can also be asymmetrically signed and encrypted to to the client if required for higher security and confidentiality, without forcing changes to OAuth.

In reality they are very similar solutions to the same problem. Assuming that Facebook adopts the final version of OAuth at some point the only real difference will be the token format, and they are using separate names so could be implemented in parallel by a provider that wanted to.

The other option.
We considered was using the id_token as the access_token.

We rejected that option because:

Many providers have existing OAuth token formats for there endpoints that would be difficult to change.

We don't want long term access tokens being stored in the browser as cookies.

There are clearly separate recipients of the two tokens overloading the semantics of the two tokens would reduce flexibility and increase complexity in the long term.

Perhaps not everyone agrees with our choices, however as I pointed out previously you can use openID Connect with only the code flow and it will still work without a is_token.

OpenID Connect is a large spec that may be intimidating to some. I hope these blog posts help implementors already familiar with Facebook Connect get comfortable with the ideas we are introducing.

John B.
@ve7jtb

Solutions for using OAuth 2.0 for Authentication

2012-01-31T16:33:00.000-03:00

In my previous post, I pointed out that OAuth 2.0 alone is an authorization protocol and can't be safely used on its own without adding additional protocol elements.

Some people might cal it a profile of OAuth, however we generally think of a profile in spec terms as a set of restrictions on a specification. As we need to add things to OAuth we are creating a new protocol using a profile of OAuth 2.0.

In fact if we look at the OAuth 2.0 specification itself we see.

OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, this specification is likely to produce a wide range of non-interoperable implementations. In addition, this specification leaves a few required components partially or fully undefined (e.g. client registration, authorization server capabilities, endpoint discovery).

This protocol was design with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.

It also has two incompatible token formats Bearer and MAC that you need to choose between before doing anything useful.

OAuth 2.0 is at the end of the day a toolkit for an authorization protocol designed to be used by many restful protocols.

So lets consider what the minimum amount we would need to specify to make a secure authentication protocol out of OAuth 2.0.

You need is a protected resource that the Authorization server is protecting.
The protected resource needs to make a user identifier available to the client.
To be interoperable with more than one Identity provider you need some concept of a issuer, the user_id needs to be scoped to the issuer by the client.
You need to define some authorization rules to say that only the resource owner can grant access to this endpoint.
You need some way to prevent clients from replying access tokens at other clients to impersonate the user.
If the protected resource, or resources have other information you need to define a OAuth scope to separate out the request to login vs other information or API the endpoints may be able to provide.
Client must provide replay protection of code.

For OAuth 2.0 you need to profile some things for interoperability and security.

Use bearer tokens (this presents opportunities for token theft that need mitigation)
Require TLS for all IdP endpoints.
Require client to track audience of access token, e.g. just because bad.com asks for a access token from google that you already have for the user, don't just give it to them.
Require preregistration of all clients, so that they have a client_id and client_secret.
Only use the code (formerly known as client-side) flow.
Make Cross Site Scripting (XSRF) protection a MUST.

This is the bear minimum that you need to do. This is not sufficient for many important use cases like Ajax clients.

To make a real protocol rather than what is effectively a authentication API for a single provider you need discovery of IdP and user identifiers like email addresses and URI.

So if that were the requirement lets consider if OpenID Connect 1.0 can be used in this simplest of ways.

Connect has a user-info endpoint returning a JSON object.
The user_id element is always provided by the user-info endpoint.
There is a Issuer that can be configured manually for every Oauth Authorization server and user-info endpoint. Connect uses a abstract URI identifier to allow IdP to reconfigure there endpoints without breaking clients.
Connect only provides authorization tokens for the user-info endpoint if approved by the user, and not by a 3rd party like a friend as in some social graphs.
If the Connect client can elect to only use the OAuth code flow.
Connect defines a scope of openid for authentication, other scopes like profile provide additional claims about the user.
Connect uses nonce to provide replay protection of id_tokens, because it supports multiple flows. A client just using code could use that to protect itself from replay.

The Connect specification profiles OAuth 2.0 using Bearer Tokens in the way described, but allows for flows other than code via additional mitigation's that I will discuss in a later post.

Connect has dynamic Discovery and Registration, but Clients are not required to support that if they have a set of well known IdP that they are willing to restrict themselves to.

So to use Connect like this you would perform a out of band configuration for each of the IdP that the client intends to use. Preconfigured buttons for each IdP would be provided for each IDP.

Diagram by Amanda Anganes (mitre.org)

Once the user clicks on a button the client stores some state in the users browser and creates a handle for it(regular OAuth 2.0).

It formulates a 302 redirect request to the known Authorization server endpoint of the issuer with it's client_id, and other OAuth 2.0 parameters.

HTTP/1.1 302 Found
Location: https://server.example.com/op/authorize?
response_type=code
&scope=openid
&nonce=
&state=af0ifjsldkj
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb

This is just Oauth 2.0 with the addition of a defined scope and nonce parameter. (nonce is used to provide replay protection for id_tokens, we are not using that in this simple example so the value can be empty)

If the user authorizes the openid grant request the client gets back a standard OAuth 2.0 response:

HTTP/1.1 302 Found
Location: https://client.example.com/cb?
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&state=af0ifjsldkj

In OAuth 2.0 the reply doesn't contain any identifying information about who sent it.
The client needs to lookup the information for state that it stored in a cookie or someplace else to know who the issuer is and verify that the request to the Authorization server came from it and not via XSRF, logging the user in via a iframe in the background.

Once the client knows who the issuer is they send the code and there client secret to the issuer's Token Endpoint via a direct request from the server.

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb

This is standard OAuth 2.0 nothing custom.

The response if the http basic authentication of the client_id and client_password are correct is:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOl
wvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIj
oiaHR0cDpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0
vzDH3T1G3liaTNOrfaeWYjuRCEPNXVtaazNQ"
}

This is a standard OAuth response with the addition of a id_token that we are going to ignore for our simple example. (The id_token is a signed token containing the user_id and other authentication information)

Diagram by Amanda Anganes (mitre.org)

Once I get my access token I can make a API request to the User Info Endpoint.

GET /userinfo?schema=openid HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X

The schema=openid parameter allows this to be added to existing endpoints that may use different schema by default. It is a fixed parameter that can be hard coded.

The response is going to be:

HTTP/1.1 200 OK
Content-Type: application/json
{
"user_id": "248289761001",
}

You now have the user_id and know the issuer so can look the user up and long them in.

If I had also asked for the profile and email scopes and the user had granted access my response would look like:

HTTP/1.1 200 OK
Content-Type: application/json

{
"user_id": "248289761001",
"name": "Jane Doe"
"given_name": "Jane",
"family_name": "Doe",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}

So would this work with Facebook?

No but mostly because Facebook is not supporting the current draft of OAuth 2.0 and OAuth Bearer Token.

However if they updated there version of OAuth it would work with only changes to the scope asked for and substituting the appropriate endpoint URI.

If we do the same example with the Facebook version of OAuth it would look like:

Authorization Request:

HTTP/1.1 302 FoundLocation: https://www.facebook.com/dialog/oauth?response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb

Difference from Connect - Facebook is not supporting state, so lack XSRF protection and force clients to have a different redirect_uri for each provider. It is not a problem for them as they assume only one identity provider. Sending no scope asks for a basket of default public claims including user_id. If you want email or address you need to include a request for those scope in the same way as Connect.

Authorization Response:

HTTP/1.1 302 Found
Location: https://client.example.com/cb?
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk

Difference from Connect - Facebook is not supporting state.

Access Token Request:

https://graph.facebook.com/oauth/access_token?
client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&client_secret=YOUR_APP_SECRET
&code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk

Difference from Connect - Facebook is passing the client secret as a query parameter in a GET, This is not allowed in OAuth 2.0 it MUST be sent as HTTP Basic authentication or in the form body of a post to keep it from leaking. Other than the OAuth difference the request is exactly the same.

Access Token Response:

HTTP/1.1 200 OKCache-Control: no-storePragma: no-cacheaccess_token=SlAV32hkKG&expires_in=5108

Difference from Connect - Honestly I don't know where they came up with URL encoding the response in the body. It has never been in OAuth 2.0 as far as I can tell. They are not returning the token type, it is just so wrong. It is the same info just in a wacky format missing some required parameters.

Graph API/Protected resource Request:

https://graph.facebook.com/me?access_token=ACCESS_TOKEN

Difference from Connect - Facebook is passing the access token as a query parameter in a GET. Another security no-no highly discouraged by OAuth (See sec 2.3).

Graph API/Protected Resource Response:

HTTP/1.1 200 OK
Content-Type: application/json
{
"id": "614345449",
"name": "John Bradley",
"first_name": "John",
"last_name": "Bradley",
"link": "https://www.facebook.com/ve7jtb",
"username": "ve7jtb",
"gender": "male",
"locale": "en_GB"
}

Difference from Connect - Facebook is returning more info by default, though it is all public by there definition. Small difference in schema.

The Differences are not that large and mostly related to OAuth itself.

This is a very limited set of features. For a real protocol we need to support Java Script clients in the browser, session management, fast login without a second network call.

I will put together another post on how Connect builds on top of OAuth to securely add these missing features.

John B.
@ve7jtb

The problem with OAuth for Authentication.

2012-01-28T17:53:00.000-03:00

I want to thank Nat Sakimura for doing a version of this post in Japanese.

In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication.

Many point to Identity Providers like Facebook to prove there point.

The problem is that OAuth 2.0 is a Delegated Authorization protocol, and not a Authentication protocol.
This is generally a four party model User, Website, Authorization server, and Protected resource.

This leads people to make what turn out to be very bad security decisions around authentication when they follow the basic OAuth flow.

Part of this is due to the activities being quite different. OAuth provides an access token to a client, so that it can access a protected resource, based on the permission of the resource owner.

I am going to use Facebook as my example, they are not the only ones to use this pattern, but they are the best well known, so make a easy target.(Sorry guys)

Diagram by Amanda Anganes (mitre.org)

In the Facebook Connect case:

The Website (client in OAuth speak) redirects the user to Facebook asking for access to the users portion of the Facebook Graph API endpoint.
Facebook gets the users Authorization to give that access.
Facebook then redirects the user back to the client passing an access token in the URL fragment.
The client performs a GET on the Facebook API endpoint using the access token from step 3.
The Graph API endpoint returns a JSON object that contains a Facebook user_id and other public and perhaps private information based on what access the user granted.
The Website logs in user in as the user_id from the Graph API endpoint.

The advantage to this is that anyone can read the instructions on the Facebook Developers Page and make there website a client.

The disadvantage is that they have no security. Not to put too fine a point on it, they have not Authenticated the User. They have gotten delegated access to the users information.

Now I know many of you are thinking John is just being overly dramatic. This is just a semantic difference that is only important to obsessives. That may be true, but in this case the difference leads to security holes that even Facebook recognizes and attempts to address in there code if not there documentation.

The problem is that the motivations of the participants are different between Authentication and Authorization. In the authorization case the client can be trusted with the access token because it has no real motivation to share it. They could give it to a third party and also grant them access to the information(protected resource), but they can just share the information anyway if they are bad.

In the above Facebook example there is a naive expectation that the access token is coming from the resource owner. Now in the Facebook case that is true only at the original token issuance.
The user is handing over access tokens all the time to Websites who use those tokens to access the Facebook Graph API.

The hard reality is that people go to questionable websites. One of the things people do at those sites is use Facebook, openID or Twitter to login. This avoids sharing there email and password with the site.

The problem is that in the authentication case Websites do have a motivation to inappropriately reuse the access token. The token is no longer just for accessing the protected resource, it now carries with it the implicit notion that the possessor is the resource owner.

So we wind up in the situation where any site the user loges into with there Facebook account can impersonate that user at any other site that accepts Facebook logins through the Client-side Flow(the default for Facebook). The less common Server-side Flow is more secure, but more complicated.

The attack really is quite trivial once you have a access token for the given user, you can cut and paste it into a authorization response in the browser.

Some people believe that using the state parameter in OAuth protects against token substitution.
The only binding a browser cookie to state protects against is Cross Site Scripting. In the attack I am proposing the client generates a legitimate request to a bad user agent that captures it and provides a response that includes state unchanged from the request. There is nothing in the OAuth client-side flow that proves the issuer you sent the request to through the browser ever received it and is the one responding. Only the access_token parameter is generated by the Authorization server, all the other parameters are dropped or echoed back. The client has no way to tell who the authorization server thought it was issuing that access_token to.

This is a security hole that you can drive a house through. As long as you don't have anything worth protecting at the Client websites it works OK, however OpenID Connect needs to address more than the simple no security use case.

Traditionally authentication involves three parties User, Relying party Web Site, and Authentication server. The Authentication server produces some sort of token/assertion for the consumption of the Relying Party (RP). This assertion in OpenID 2.0 and SAML 2.0 contain a way to identify who (what RP) the token was created for. The RP only accepts tokens addressed to it. This prevents RP's and others from replaying tokens at different RP.

In OAuth the token is intended for the consumption of the protected resource, and intentionally opaque to the client (RP). The RP has no way to tell from the token if it was generated for it or another RP.

You could say the audience for the OAuth token is the protected resource and the audience for a authentication token is the RP. They are not the same endpoint!

How is Connect Different from plain OAuth?

We needed to add the appropriate security and semantics for authentication without compromising OAuth's functionality as a Authorization protocol.

One idea we explored was adding a audience claim to the protected resource(User Info Endpoint).
This requires communicating the OAuth client_id from the authorization endpoint to the protected resource. The biggest problem is that the RP is required to do a network operation in the background to get the user_id before logging the user in.

Many RP including Facebook stated that the extra latency in the network round trip was unacceptable.

Now you are thinking how can that be if that is way Facebook is doing?

Well it turns out that they have some undocumented enhancements to get around the latency issue.
They are using something they call signed-request.

The idea is that they are encapsulating the OAuth code token inside a "signed" JSON object.

The SDK they provide is looking for user_id in the signed request and using that to log the user in before doing any back channel OAuth requests. This provides an implicit audience restriction by the client verifying a symmetric client password used to generate a HMAC over the token.

To be clear Facebook is NOT using the signed_request as the access_token they are extracting code from the signed_request and exchanging that for a access_token at the Token Endpoint.

One thing OAuth 2.0 allows is defining new Response Types. Based on OAuth 2.0 Multiple Response Type Encoding Practices by Google and Facebook, we decided to use a separate id_token parameter in the response rather than overload the access_token. That allows the tokens to have separate audience restrictions and formats. Facebook is doing the same thing but are using signed_request rather than id_token as the response type. We both return the extra token fragment encoded win an additional parameter, in Facebooks case signed_request and in openID's id_token.

Connect documents having two tokens one for authentication and one for delegated access to protected resources. Facebook's documentation on this could use some improvements.

Connect is also using a proposed IETF standard for Javascript Object Signing and Encryption (JOSE) rather than proprietary method. We hope that the availability of standard libraries will improve security, and reduce developer effort.

Connect has had to take into consideration that RP will be dealing with multiple Identity Providers, unlike single provider protocols.

When creating a protocol there is always a balance that is struck between having a single tool that is flexible vs multiple highly optimized ones. I don't think having each identity provider deploy there own incompatible identity layer on top of OAuth is good for RP or adoption. We came up with a compromise that is not optimized to only serve a single use case, though we have made the simple social login use case no more complicated for the RP than Facebook Connect.

Many of the optional features for higher security and distributed claims will only be used by those sites that need them, however it will give a clear migration path for sites starting with social login.

The specification looks a bit scary because for interoperability reasons we need to document the server side. Nat's blogpost on OpenID Connect in a Nutshell lays out how simple it is for a RP to implement.

I hope this helps explain some of the value that Connect brings to OAuth.

John B.

@ve7jtb

OpenID Connect Scopes and Claims

2012-01-26T14:10:00.000-03:00

We have had a number of people wanting more information on the use of scopes and claims in openID connect.

Nat Sakimura has put together a blog post explaining some of of the details.

I am starting to see more people coming up with ways to use the aggregated and distributed clams functionality of Connect to solve there use cases.

John B.
@ve7jtb

Facebook diverges from OAuth 2.0 Specification

2012-01-26T11:01:00.003-03:00

Currently the method for OAuth clients to get access to the Facebook graph API while the user is not logged in (to the client), is to ask for a special scope of offline-access.

If the user grants permission the access token will not expire until the user explicitly removes the permission for the client.

Facebook has announced that this feature is changing.

It looks like they are modifying there token endpoint for extending access tokens rather than using refresh tokens.

My read of it is that developers will now get offline access without asking. They just need to refresh the access token every 60 days.

The documentation is typical of Facebook so the actual operation may be different.

Using the 'code token' return type with a refresh token would have been OAuth 2.0 compliant.

They seem to have decided to extend OAuth 2.0 in a custom way rather than using a core feature.

I expect the media may jump on the privacy issue.

This may also be part of the normal strategy of announcing something then balking off if people object.

I am philosophical about Facebooks privacy. My real concern with this is the divergence from the OAuth 2.0 specification.

John B.
@ve7jtb

OpenID Connect in a Nutshell

2012-01-24T23:41:00.001-03:00

Nat Sakimura has written a valuable post describing OpenID Connect in a nutshell. It shows by example how simple it is for relying parties to use basic OpenID Connect functionality. If you’re involved in OpenID Connect in any way, or are considering becoming involved, his post is well worth reading.

John B.
@ve7jtb

FICAM SAML 2.0 Web SSO Profile updated

2012-01-19T13:33:00.000-03:00

The updated version of SP-800-63-1 is official as of Dec 2011.

The FICAM SAML 2.0 Web SSO Profile has been updated to reflect some clarifications.

The major change is that SAML assertions using the POST binding are no longer required to be encrypted, as long as all of the endpoints are using TLS.

The relevant section 9.2.1 from SP-800-63-1

Secondary authenticator capture – To mitigate this threat, adequate protections shall be in place throughout the lifetime of any secondary authenticators used in the assertion protocol.
1. In order to protect the secondary authenticator while it is in transit between the Verifier and the Subscriber, the secondary authenticator shall be sent via a protected session established during the primary authentication of the Subscriber using his or her token. This requirement is the same as the requirement in Section 8, regarding the Authentication Process, to protect sensitive data (in this case the secondary authenticator) from session hijacking attacks.
2. In order to protect the secondary authenticator from capture as it is submitted to the RP, the secondary authenticator shall be used in an authentication protocol which protects against eavesdropping and man-in- the-middle attacks as described in Section 8.

There is a second factor with respect to XML encryption to consider here as well.

The commonly AES-CBC encryption is susceptible to a padding oracle attack.
In most SAML implementations without additionally signing and verifying the message, the assertion can be decrypted by an attacker.

Perhaps the more interesting aspect to this change, is that the lack of end to end encryption through the browser was the main reason openID 2.0 was limited to only LoA 1.

At some point FICAM may decide to revisit the existing openID 2.0 profile and allow it to be used at LoA 2.

I think that the openID Connect Basic client profile now meets all of the revised requirements for LoA 2 as long as the RP is using TLS. With a very small update it could also be suitable for LoA 3.

The full openID Connect spec supports end to end encryption with integrity that is not susceptible to the padding oracle attack. It was designed to support profiles with the highest security and privacy requirements.

As a start updating the openID profile would encourage openID providers to start looking at Identity proofing and the other LoA 2 issues as they start planning there migrations to Connect.

John B.
@ve7jtb