Thread Safe

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

Javascript Object Signing and Encryption (jose)

2012-01-17T17:12:00.003-03:00

The initial drafts of JOSE are posted to the IETF WG.

They are refactored from the previous individual submission versions to move algorithms and identifiers into a separate specification, per the working group charter. Also, per the working group’s input, the terminology usage has been changed to no longer call both digital signatures and HMACs “signatures”. The JOSE versions contain no normative changes from the individual submission versions.

John B.

openID Board Elections 2012

2012-01-04T17:34:00.004-03:00

Please run if you are interested and a member.

If you are not a member please join.

I am hoping that we can at least maintain or increase our European representation.

The official announcement is on the OIDF site.

LoA Registry

2011-12-28T13:56:00.000-03:00

This is the registry that we reference from the Connect specs for registering Authentication Context Class References (acr) short names in Sec 2.1.1 of Connect Messages.

A new version of I-D, draft-johansson-loa-registry-03.txt has been
successfully submitted by Leif Johansson and posted to the IETF
repository.

Filename: draft-johansson-loa-registry
Revision: 03
Title: An IANA registry for Level of Assurance Profiles
Creation date: 2011-12-29
WG ID: Individual Submission
Number of pages: 7

Abstract:
  This document establishes an IANA registry for Level of Assurance
  Profiles. The registry is intended to be used as an aid to
  discovering such LoA definitions in protocols that use an LoA
  concept, including SAML 2.0 and OpenID Connect.

Connect Implementers Draft

2011-12-23T11:13:00.001-03:00

After many months of work, review and test implementations by people from around the world, we are moving on to the next step in the openID specification process.

Today we have published the final specification documents for the Implementers Draft of Connect 1.0.

This will let us have a couple of days off over Christmas while the members who have not been actively tracking the spec give it a good read. Think of it as a Christmas present:)

The 45 day public review period ends Feb 6, 2012.

Unless serious issues are identified, there will be full membership vote on the Implementers Draft starting immediately after the review period closes. This vote serves to lock in the IPR contributions of all of the Work Group participants.

This is not the final specification. There may be changes as a result of the implementations and interoperability testing feedback, before the final version of the Specification is put to a membership vote later in 2012.

If you want to vote in the upcoming board election and for or against the Implementers Draft, you can join the Open ID Foundation.

The following is the official announcement from the Connect Working Group.

Subject: Review of Proposed OpenID Connect Implementer’s Drafts

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. This note starts the 45 days public review period for the specification drafts in accordance with the OpenID Foundation IPR policies and procedures. This review period will end on Monday, February 6, 2012.

Unless issues are identified during the review that the working group believes must be addressed by revising the drafts, this review period will be followed by a seven day voting period during which OpenID Foundation members will vote on whether to approve these drafts as OpenID Implementer’s Drafts.

The specifications are posted at these locations:

• http://openid.net/specs/openid-connect-basic-1_0-15.html

• http://openid.net/specs/openid-connect-discovery-1_0-07.html

• http://openid.net/specs/openid-connect-registration-1_0-08.html

• http://openid.net/specs/openid-connect-messages-1_0-07.html

• http://openid.net/specs/openid-connect-standard-1_0-07.html

• http://openid.net/specs/oauth-v2-multiple-response-types-1_0-03.html

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

Information on joining the OpenID Foundation can be found at https://openid.net/foundation/members/registration. Foundation members will be asked to vote on approving these specifications as Implementer’s Drafts.

You can send feedback on the specifications in a way that enables the working group to act on your feedback by (1) signing the contribution agreement at http://openid.net/intellectual-property/ to join the AB+Connect working group, (2) joining the working group mailing list at http://lists.openid.net/mailman/listinfo/openid-specs-ab, and (3) sending your feedback on that list.

OpenID Connect, A tale of two Tokens

2011-11-02T12:52:00.000-03:00

I keep getting the question "Why are there two tokens in openID Connect?"

There were a number of design requirements that we had going into the specification process:

1 - A requirement from RP (Relying Parties) is quick customization and display of the user interface after login.

They required sub second response to the user. This did not allow for a additional round trip to the IdP to get the userID. Adding multi second delays above a password authentication is not deployable for many of them.
Facebook is using signed request to pass the userid in the response, the client verifies the signature, and can immediately display the user interface.

2 - Salesforce and other IdP have existing user-info endpoints and other protected resources that they want to add as scopes to the access token.

A requirement is to not break existing implementations by forcing them to use a different access token format.

3 - T-Mobile and others pass signed tokens to there endpoints containing there scopes.

A requirement is to be able to only pass the required info in the token to the protected resource. That resource may be controlled by a 3rd party so sending the user_id may be leaking privacy information.

4 - Google and others had a requirement that Connect support multiple client types especialy Ajax in the browser.

5 - Everyone agreed that you can't step the user through multiple authorizations one for each resource.

We know that to meet requirement 1 we need to send a signed token with the user_id in it to the RP, and it needs to be in the response from the Authorization server.

So we need a id_token. Facebook has a proprietary format called signed request , We worked with the community to come up with JWT a more general purpose open standard similar to signed request but also supporting encryption.

One of the ways OAuth 2.0 deals with creating multiple tokens for different protected resources is down-scoping. You ask for multiple scopes in the authorization request, perhaps one for each resource.

The Authorization server then gives you Refresh Token good for all of the scopes. You then go back to the token endpoint and ask for a new token with only some of the scopes.

Down scoping has some issues, but the big one is that it is only available with the code flow and that violates requirements 1 and 4.

That leaves us with several options:

Using the id_token as the access token.
Including a access_token in the id_token.
Returning two tokens

Using the id_token as the access token breaks requirement 2, as well as creating some additional security concerns about storing something that may be a long-lived access token in the browser as a session cookie.

Including the access token in the id_token is the route that Facebook Connect chose. That works for requirements 1, and 2. It also has some problems if the RP wants to use the id_token for session management. You wind up with long lived access tokens embedded in session cookies. The id_token also get quite large. This accomplishes 3, in that the access_token is not carrying extra user information.

Returning two tokens in the response from the authorization server meets all of the requirements.

The information about the authenticated user is kept separate from the access token.
The size of the id_token can be much smaller.
If the id_token is used as a session cookie, no access token is leaked.
The access_token can be a signed token as well including only the required information.
We still have all of the down-scoping options available when using the code flow.
The id_token can be bound to the lifetime of the user session, separating it from the lifetime of the access_token.
The audience for the two tokens can be separate, and it makes encrypting them for there respective audiences simpler.

Typically a RP using the implicit OAuth 2.0 flow will get the id_token in the response from the Authorization server to there registered redirect endpoint. They then validate the signature and use the included user_id to customize the web page, while they make an additional OAuth 2.0 authenticated request to the user_info endpoint if required. This allows returning users to be logged in quickly from there perspective. A new user will have a small rely before the profile information is retrieved.

There are a number of new OAuth 2.0 response_type that openID Connect is registering for OAuth 2.0, these will allow several options on how the tokens are returned to fit the varied client requirements.

We are also working on a session management and single logout extension that leverages the id_token.

As perhaps partial validation of having a separate token the SAML WG at OASIS has a session token profile in public review currently.

While a single token seems tempting there are overwhelming reasons it won't work for many of our use cases. I was the one who argued for the single JWT token and lost.

I will do a post on the response_type openID Connect soon.

John B.

Updated JWT and related specs posted

2011-10-31T21:22:00.000-03:00

We have posted updated versions of the JSON Web Token (JWT), JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. No changes should be required to any existing deployments as a result of these updates.

These are used by openID Connect.

The primary thrust of these changes was updating the JWT spec to describe how to create and process encrypted JWTs. (The previous JWT spec pre-dated publication of the JWE spec.) I also removed duplicate content from the JWT spec describing the steps to sign JWTs and instead simply referenced it in the JWS spec. Numerous suggestions on improving the specifications from the WOES and JOSE lists were also incorporated. The changelog entries are as follows:

draft-jones-json-web-token-06

· Reference and use content from [JWS] and [JWE], rather than repeating it here.

· Simplified terminology to better match JWE, where the terms "JWT Header" and "Encoded JWT Header" are now used, for instance, rather than the previous terms "Decoded JWT Header Segment" and "JWT Header Segment". Also changed to "Plaintext JWT" from "Unsigned JWT".

· Describe how to perform nested encryption and signing operations.

· Changed "integer" to "number", since that is the correct JSON type.

· Changed StringAndURI to StringOrURI.

draft-jones-json-web-signature-03

· Simplified terminology to better match JWE, where the terms "JWS Header" and "Encoded JWS Header", are now used, for instance, rather than the previous terms "Decoded JWS Header Input" and "JWS Header Input". Likewise the terms "JWS Payload" and "JWS Signature" are now used, rather than "JWS Payload Input" and "JWS Crypto Output".

· The jku and x5u URLs are now required to be absolute URLs.

· Removed this unnecessary language from the kid description: "Omitting this parameter is equivalent to setting it to an empty string".

· Changed StringAndURI to StringOrURI.

draft-jones-json-web-encryption-01

· Changed type of Ephemeral Public Key (epk) from string to JSON object, so that a JWK Key Object value can be used directly.

· Specified that the Digest Method for ECDH-ES is SHA-256. (The specification was previously silent about the choice of digest method.)

· The jku and x5u URLs are now required to be absolute URLs.

· Removed this unnecessary language from the kid description: "Omitting this parameter is equivalent to setting it to an empty string".

· Use the same language as RFC 2616 does when describing GZIP message compression.

draft-jones-json-web-key-02

· Editorial changes to have this spec better match the JWT, JWS, and JWE specs. No normative changes.

The specs are available in the standard places. The HTML versions can be found at these locations:

· http://tools.ietf.org/html/draft-jones-json-web-token-06

· http://tools.ietf.org/html/draft-jones-json-web-signature-03

· http://tools.ietf.org/html/draft-jones-json-web-encryption-01

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

· http://self-issued.info/docs/draft-jones-json-web-token-06.html

· http://self-issued.info/docs/draft-jones-json-web-signature-03.html

· http://self-issued.info/docs/draft-jones-json-web-encryption-01.html

· http://self-issued.info/docs/draft-jones-json-web-key-02.html

GÉANT Federation Lab & OpenID Connect

2011-10-04T12:12:00.000-03:00

GÉANT Federation Lab is working on adding OpenID Connect support.

This is a sneak preview of parts of the user interface.

Longer video of beta interface for Federation Lab.

Links for 2011-09-13 [del.icio.us]

2011-09-14T00:00:00-07:00

Cloud Security: Open Source Identity Management Software

Links for 2011-09-10 [del.icio.us]

2011-09-11T00:00:00-07:00

Cloud Security: Open Source Identity Management Software

Account Chooser

2011-08-26T12:04:00.001-03:00

Eric Sachs just published a website at accountchooser.com as an initial proposal for an account chooser user interface. It includes a first draft of suggested UI guidelines at http://accountchooser.com/ux.html.

The next step is to create a formal OpenID working group to further refine those user interface specifications. See the draft charter at:

https://sites.google.com/site/oauthgoog/workinggroupcharter

OpenID Connect Nonce

2011-08-24T13:53:00.000-03:00

Question:
I cannot find a good description of the purpose of the nonce parameter. I believe there can be more than one answer to that. Is the provider expected to not accept nonce values that have been used in the past?

Answer:
The nonce ties the session to the issued id_token.

The RP generates the nonce.

The IdP MUST return the nonce unchanged as the value of the id_token "nonce" parameter.
The IdP MUST NOT reject duplicates.

The OAuth state parameter not being signed in the response is designed to stop XSRF, but not other cut and paste attacks that might happen in the the browser.

As a RP/ Web Server Client, I would use a hash of the session cookie as the nonce and state value.

That way when I get the id_token in ether the fragment via the implicit flow or from the token endpoint in the code flow, I can bind the session to the id_token in a way that is not the result of a cut and paste attack in the browser using a stolen token.

The reason for the IdP to not reject duplicate nonce is that it might legitimately be a second request bound to an existing session.

I will try and clarify that in the spec.

Mind you this only protects SSL RP as if you can fire sheep someones session you would also get the session cookie. (Non SSL RP over open wireless are not possible to protect)