identity 1.0 documentation

Discussion

«  Resource   ::   Contents   ::   Decoupling Identity and Authentication  »

Discussion

TOC

Breaking change in OAuth 2.0 rev. 23

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001672.html

I only noticed now that rev 23 had a breaking change. it seems to doesn’t allow the response_type=code token unless we define another client type such as “hybrid”.

This is a breaking change.

I wonder why I did not notice it till now.

See below.

>From section 2.1 of http://tools.ietf.org/rfcdiff?difftype=–hwdiff&url2=draft-ietf-oauth-v2-23.txt

“A client application consisting of multiple components, each with its own client type (e.g. a distributed client with both a confidential server-based component and a public browser-based component), MUST register each component separately as a different client to ensure proper handling by the authorization server.”

Discuss.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001673.html

Yes I didn’t see any discussion on that before the change.

It is unclear if you can define a new client type, it is not a real parameter.

Perhaps it is enough to say that any client asking for code token is hybrid and needs to be treated appropriately. Though that section seems to make having a separate client_id for each component mandatory.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001674.html

Yes I didn’t see any discussion on that before the change.

It is unclear if you can define a new client type, it is not a real parameter.

Perhaps it is enough to say that any client asking for code token is hybrid and needs to be treated appropriately. Though that section seems to make having a separate client_id for each component mandatory.

Indeed, and that’s the breaking point.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001675.html

The way I read it, “code token” is its own type, and it needs to be treated differently from either “code” or “token”, which isn’t a change. What the intent of the text is, I believe, is to keep people from using the same client id with “code” as with “token”. This would effectively be mixing public and private clients in the most normal use cases, which is the section that it’s in, and that’s not a good thing.

I don’t think it’s actually a breaking change, but I’m less convinced of the utility of normative language here.

– Justin

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001676.html

The way I read it, “code token” is its own type, and it needs to be treated

My first take was that but the text goes:

a distributed client with both a confidential server-based component and a public browser-based component), MUST register each component separately as a different client

so looks to me that it does not allow that interpretation...

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001684.html

A related question came up on the OAuth WG list: http://www.ietf.org/mail-archive/web/oauth/current/msg08548.html though I don’t know if that provides much guidance.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001677.html

This is the only discussion about this change. http://www.ietf.org/mail-archive/web/oauth/current/msg08271.html

And this is the response I got in OAuth ML. http://www.ietf.org/mail-archive/web/oauth/current/msg08548.html

According to the Eran’s reply, I thought extensions (eg. response_type=code token) can overwrite the requirement.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001678.html

The problem is the normative MUST language. If it were SHOULD, it is less of the problem.

Since it is a MUST, we cannot extend it. That is the problem that I am pointing out.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001679.html

Not true – extensions can override MUST requirements if they specify the conditions that break it.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001682.html

Good to know it. I thought an extension could only extend from an extension point but could not override a normative language. If it can, it would not be a problem.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001685.html

I am quite confused with this change.

In particular, I am not sure response_type is anymore relevant. Can’t it be inferred from the client, since each client is bound to a security context?

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001686.html

If we’re concerned about this change, we should begin discussing it on the OAuth mailing list and lobbying to have it undone. Discussing it on the AB list won’t accomplish this.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001687.html

I agree and I am planning to raise the issue here. However, I would like to register it here that I don’t think the current approach to defer to extensions is necessarily sufficient to remove all cause for concern by this WG.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001688.html

> If we’re concerned about this change, we should begin discussing it on the > OAuth mailing list and lobbying to have it undone. Discussing it on the AB > list won’t accomplish this.

I just sent a message to the OAuth list in this regard. Yes, I think this should be debated there.

Marius

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001689.html

So it was my attempt to see if it were a problem that we can solve here or not and good to hear that you filed it to the oauth list.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001680.html

The change does not preclude these being the same physical client

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001681.html

Right, this, too. A client could effectively have two personae.

Does Connect support public clients?

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001592.html

Hi all,

I’m unable to find out whether OpenID Connect supports public clients. It seems Connect assumes all clients register with the OP and obtain a client credential. If this observation is correct, what is the reason for being more restrictive than OAuth?

regards, Torsten.

Torsten,

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001598.html

From your tickets it looks like you are thinking that the Basic client profile is for JS clients in the browser doing canvas type Aps and directly accessing the check_id and user_info endpoints.

The idea for what i’t worth was that it is intended to be a Web server profile that uses the browser side implicit flow, with a simple sever side callback that extracts the fragment and passes it to the server for processing and verification. That is why Cross Origin Resource sharing is not mentioned win that profile.

It is true that that profile could be used for a Canvas type JS app in the browser accessing the endpoints as well.

Would your preference have been to make the basic client use the code flow? It is arguably similar in complexity at the end of the day, but with better security for Web Server type applications.

I would probably just have the client base64 decode the id_token and forget calling the check_id endpoint. If the client doesn’t have the correct token endpoint and gives the client secret to it checking the signature on the id_token is not very useful:)

Regards John B.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001596.html

All clients must register there redirect_url and get a client_id.

They are not required to use the client secret if they are public clients.

We talked about allowing a client_id of “public” and not requiring pre-registerd redirect_uri, but the feedback was that IdP were uncomfortable giving access tokens to unknown clients.

OAuth recommends against public clients with unregistered redirect_uri.

In a effort to have some balance we do have dynamic registration for clients.

If a user wants to revoke a client not having all of them with the same client_id is probably an advantage.

If it is something you think you need I am open to discussing it.

John B.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001599.html

I would prefer to have the Basic Client use the code flow for another reason: the code flow is the only one that’s mandatory to implement for the server. So what we have right now is advice for servers to implement something that our advice to clients say they don’t have to.

– Justin

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001600.html

Both code and ‘token id_token‘ should be mediatory to implement for servers.

Is there a particular place that you are seeing that in the spec. I think that is a bug, if true. I will look for it today.

If the WG did want code to be the only MTI flow then we would defiantly need to change the basic profile to code.

John

MTI flow
MTI Token
MTI
mandatory-to-implement

may be Mandatory-To-Implement flow. Connect Basic MUST implement “code” and “token id_token”.

OAuth MTI token discussion is http://www.ietf.org/mail-archive/web/oauth/current/msg07906.html

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001601.html

Hrm. Reading through the drafts again just now, it does clearly say that ‘code‘ and ‘token id_token‘ are MTI, so I’m not sure where I got that impression from. My mistake.

– Justin

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001602.html

No problem, sometimes even I am surprised by things that have snuck in or are left over from older versions.

Do you still prefer the code follow for the basic client profile?

John

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001603.html

Yes, I certainly do. It’s cleaner in design, its pattern is more proven, and it can be implemented in all kinds of different clients, even lightweight Javascript ones.

The implicit flow is an optimization for fewer network calls, and it’s always felt more like a codified hack than a real protocol flow to me. Whenever I’ve seen somebody pressed on the issue of whether or not their clients could really support the code flow, they’ve admitted that yes, they could, but they didn’t want to pay the time costs of a second round trip to the server.

We’re also concentrating on the code flow for our own Connect deployment, and we’ll patch in the implicit flow sometime later.

– Justin

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001604.html

As I recall it was Facebook and Google who were keen on the implicit flow.

Part of the argument was that it was easier to get someone to implement it by dropping some JS code on their site for the callback URI and setting the id_token as a cookie.

It is a different approach than the more traditional library one, that fits the code flow better.

I am not personally attached to the implicit flow.

However we probably need wider feedback before changing the basic client profile.

John

Note

Implicit Flow advantages:

  • Easier to deploy: Just drop Facebook/Google provided Javscript on your pages.
  • ID Token can be user agent authenication cookie. It is good for big cloud providers like Google/Facebook.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001627.html

> As I recall it was Facebook and Google who were keen on the implicit flow.

Actually, I think I suggested at least once to have ‘code‘ be the basic flow in OpenIDConnect. Not that I think the current approach of using ‘token’ to have been a bad decision. Just that I don’t have a strong view either way.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001628.html

It was a close decision, as I recall. Both flows work almost equally well.

The question was what would look simpler for a client to implement.

I think the thought at the time was that we could produce a JS that someone could drop on their site and have them up and running with the Basic profile without significant server side programming.

One thing we are missing for the current Basic profile is that drop in JS code example.

Without the implicit example/template JS the code flow may be simper for server side programers to understand.

John B.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001629.html

The token flow is simpler if there’s an existing corroborating server page with the returned javascript, which is the Facebook use case. Without that existing code, as John points out, it’s no simpler than the code, and potentially more complex to implement securely.

– Justin

Note

Javascript proof sample is required for Basic RP implementer.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001630.html

This sounds to me like an argument for us to create the JavaScript code so the promise of clients not having do any substantial programming to use Connect can come true. That’s the reason we chose the implicit flow, and why I think we should make it possible by getting the code written.

The process of writing the code might also give us valuable feedback on the specs, while we’re still at Implementer’s Draft stage.

Who would make sense to write that code? Maybe we could use some directed funding to make it happen???

– Mike

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001631.html

There are two approaches we could take with the JS code.

The simple one is the example code I posted earlier in the thread that the client puts at it redirect_uri and it takes the fragment and sends it to the Web server client via POST for parsing.

The more complicated one would be to have the JS make the and process the response setting the validated id_token as a cookie and save the user_info attributes to HTML local storage or post them back to the Web Client.

That would be the most standalone example. Include a JS login widget and it will set a openID cookie once they are logged in. The Web Client just needs to validate the signature of the id_token.

There are probably in-between states. There is probably example code around for most of that, someone needs to put it together and clean it up.

John B

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001632.html

Let’s add discussion of getting this code written to our agenda for the in-person working group meeting.

– Mike

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001636.html

+1

Unlike FB Connect, we do support asymmetric signature so the signature validation actually can be done by the JS client as well.

=nat

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001637.html

Yes, but the Basic client profile is only using symmetric signatures.

The other issues is even if the JS client can validate the signature the Web server still can’t trust the validation, it needs to validate the assertion itself before releasing any of it’s resources to the client.

I suppose one interesting option we haven’t talked about is using the id_token as the access_token for additional API resources on the Client Web Server. That should work quite nicely given the id_token has the client as it’s audience already.

John B.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001638.html

In the case of FB, only the way that the web server can protect itself and the user is to send the access token to an undocumented api /app and get the intended client_id.

That is just like the check id endpoint except that it is using access token instead: i.e., it is a Check access token endpoint. We could define such an extension endpoint.

Nat

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001639.html

The current proposal is to add a hash of the access_token to the id_token so that we would not need a separate access_token introspection endpoint.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001605.html

Actually, after Johns blog post about the vulnerability of OAuth as authentication, I got a strong feedback from security and privacy community that it is insane to send the token to the server. The token was issued to the user agent and sending that to the server constitutes security, privacy and policy breach. If we are to avoid sending token to the server, implicit flow is not simple any more. We have to use CORS or postMessage inter frame communication etc.

That is another reason to consider the possibility of making the code flow the default.

Nat Sakimura

Note

To whom Implict tokens are to be issued ?

  1. User Agent : User must grant to issue a token to UA where his privacy data is used at.
  2. User Agent and Client : Javascript and pages are controlled by Clients anyway.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001606.html

+1 pro code as default flow Gesendet mit BlackBerry® Webmail von Telekom Deutschland

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001625.html

Actually, I am not suggeting to through current Basic Client (side flow) Profile.

I was suggesting that perhaps it would be worthwhile to have appropriately constrained Basic Server side flow Profile as well.

Reading through some of the FB documentation, I believe it does not have to be in the RFC format, really. For those people who wants to read only a concise document, a white paper or a blog post like thing in a similar manner to http://nat.sakimura.org/2012/01/20/openid-connect-nutshell/ would be more valuable, I suppose.

=nat

Note

Could be two basics:

  • Basic Client Side
  • Basic Server Side

Response types clarification

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001588.html

oHi all,

I’m trying to catch up with the Implementors Draft and need some advice from the group.

Is it correct that “code” is the only response type, which is delivered to the client via URI query parameter? For all other response types, the response parameters are encoded within the URI fragment.

Furthermore, is the client always issued an access token _and_ an id_token for scopeopenid” and response typecode”?

thanks in advance, Torsten.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001590.html

> Is it correct that “code” is the only response type, which is delivered to the client via URI query parameter? For all other response types, the response parameters are encoded within the URI fragment. Yes > > Furthermore, is the client always issued an access token _and_ an id_token for scope “openid” and response type “code”?

The response from the Authorization server is code as was asked for.

The Token endpoint includes id_token in it’s response as an extra parameter.

So strictly speaking Yes id_token is always issued if the scope is ‘openid‘ (scope is a single value with spaces, so don’t say includes) and the response_type is code.

However the response type is code and only code.

scope response_type response in
openid code code query
openid token id_token token id_token fragment

The id_token is only returned if code is exchanged at the token endpoint for and access_token and id_token.

So I suppose you could avoid getting id_token by not exchanging code, but I don’t think anyone is going to think that is a good idea.

The problem is that response)type only controls what comes back from the Authorization endpoint, and not the token endpoint.

The only option we found was overloading a scope to change the behaviour of the token endpoint to return the extra value.

The token endpoint response is direct, so size is not a big issue. It was simpler to always return it from that endpoint than create a complicated way of asking for it from the token endpoint.

Worst case the response is a bit bigger, but the client ignores the extra parameter.

John B.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001591.html

Hi John,

thanks for the clarification.

So all response types containing the string value “id_token” cause the authorization server to directly return a id_token (along with all other parameters) to the client via fragment?

regards, Torsten.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001595.html

Response types are single values. (I am starting to hate Erin’s compromise) [1]

[1]What compromise ?

The response types are documented in: http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html

The response types “code id_token”, “id_token token”, and “code id_token token” MUST return a id_token and the response SHOULD be fragment encoded.

Now you are asking yourself why is that SHOULD be fragment encoded as opposed to MUST be fragment encoded.

The reason for that is that the response_type registration is leaving wiggle room to use the same response type with post message as well.

For that to work the client would need to register a JS Origin and DOM Channel Names(or pick a fixed strings).

We did stub in post message configuration parameters, but removed them due to there not being a OAuth spec yet.

Probably more than the yes you were looking for, but the history provides some perspective.

John B.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001608.html

Hi John,

thanks again for the clarification. HTTP/HTML can be so complicated :-(

Another question crossed my mind: The number of response types really struck and confused me during my first read and I assume this will happen to others as well. Why not significantly reduce the number of response types by

  • not combining code and token and
  • just using “token” instead of all combinations of id_token and token ?

The response type “token” could cause the OP to return both the id_token and the access token in the fragment, which is similar to the response of the tokens endpoint. I know this would return tokens the client is potentially not interested in. But this seems to be accepptable for the code response type.

regards, Torsten.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001610.html

> - just using “token” instead of all combinations of id_token and token ? > > The response type “token” could cause the OP to return both the > id_token and the access token in the fragment, which is similar to the > response of the tokens endpoint. I know this would return tokens the > client is potentially not interested in. But this seems to be > accepptable for the code response type. >

I actually rather like this approach. It keeps the question of whether or not you want OpenID confined to the value of the ‘scope’ field (that is, presence of an ‘openid’ value in there), and it makes serialization of the ID Token just a part of the access token output, like the code flow with the token endpoint. Of course we still have to profile how it gets encoded, but it’s ultimately another field in the token output.

– Justin

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001611.html

That was the way we originally had it. Later on people thought that using the OAuth multi-response type was more OAuth friendly.

Originally if you had the scope openid:

1 response_type=code both code and id_token were query encoded in the response 2 response_type=token both access_token and id_token were fragment encoded.

There was no way to just get code or access_token, and no way to get just id_token.

It was simpler I will give you that.

It is a bit different from adding id_token to the token endpoint in that there is no OAuth mechanism for controlling the response from the endpoint. I suppose the alternative would have been to add an extra parameter to the token endpoint request to say if you wanted a id_token.

Again the problem is that the response types are not really combinations of token id_token but entirely new response types that contain the substrings token or id_token to confuse developers.

John

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001612.html

> That was the way we originally had it. Later on people thought that using the OAuth multi-response type was more OAuth friendly. > > Originally if you had the scope openid: > 1 response_type=code both code and id_token were query encoded in the response

Query encoding id_token leads to increased privacy risks.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001613.html

Yes query encoding of id_tokens runs the risks of leaking them through logs, proxys, and most of all through referrer.

One of the reasons for the change in the later drafts.

You can protect against referrer leaking but that requires a level of client sophistication that is unlikely in the wild.

I should mention that POST responses were an option in openID 2.0, but are not in OAuth (for lots of good reasons).

The fragment encoded response is also less size constrained in many cases, especially if the JS is using POST to push the parameters to the server.

Note

No POST response in OAuth 2.0

John B.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001614.html

Hi,

John Bradley <ve7jtb at ve7jtb.com> schrieb:

>Yes query encoding of id_tokens runs the risks of leaking them through >logs, proxys, and most of all through referrer. >

I’m getting confused. Didn’t you say in your response to my posting regarding id tokens as URI query parameters security was not the reason for not transmitting id tokens that way?

>One of the reasons for the change in the later drafts. > >You can protect against referrer leaking but that requires a level of >client sophistication that is unlikely in the wild. > >I should mention that POST responses were an option in openID 2.0, but >are not in OAuth (for lots of good reasons). > >The fragment encoded response is also less size constrained in many >cases, especially if the JS is using POST to push the parameters to the >server. >

What is the difference between the POST binding and a JS pushing the token via POST request?

regards, Torsten.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001615.html

The redirect response with a id_token is no more likely to leak than a openID 2 redirect response.

The main reason was functionality the fragment response works for both web servers and JS clients.

Leaking the id_token is more of a privacy problem than a security one.

Breno is correct that fragment has better privacy less leakage.

The difference between a post redirect and JS pushing via POST is the large browser warning if you are going between https and non https endpoints and other strange side effects of cross origin POSTs.

The JS version is less prone to freak out users.

John B.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001617.html

I appreciate that you are trying to catch up with the logic of decisions made over a multi year development process that involved a large number of people.

I am trying to fill in the colour as best as I can remember, as one of the editors.

OAuth 2 itself also changed under us during the process as well.

Fortunately or unfortunately making breaking changes at this point will require a supermajority of the WG, now that we have implementers drafts in peoples hands.

Non normative changes are not going to be a big issue if we find things that need further clarification or outright bugs.

I expect that additional profiles for things like code flow are probably a good idea even if we leave the Basic Client profile as is.

We just need to decide if they are normative and part of the specs or non-normative implementers guides. Basic is a bit of a mix as it was intended to work as a standalone document without referencing the other parts of the specs.

I am still trying to figure out why you are getting the impression that the Basic profile is just for JS clients?

John B.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001640.html

Hi John,

Am 21.02.2012 20:48, schrieb John Bradley: > I am still trying to figure out why you are getting the impression that the Basic profile is just for JS clients?

I’ve got a basic understanding of how it is supposed to work for web applications. But I suspect I’m not the only one considering it rather complicated.

Let me revisit the flow (after sucessful login):

  1. the OP redirects back to the redirect_uri (client web site)
  2. the web site uploads HTML and pieces of JS to the client
  3. the JS code extracts the id_token from the URL fragment and posts it to its backend

So the RP implementation requires a combination of backend and client side code. Furthermore, the RP needs to process two (or more? - see below) calls to perform the login. In contrast, a login based on the code flow can be implemented in the backend only and requires only a single request on the RP.

In my opinion, the Basic profile is opimized from a OP perspective as it minimizes calls and (potentially) shared state on the OP’s side whereas the code flow is easier to use from a RPs perspective.

Further questions regarding Basic profile: How are client and server state synchronized with respect to the user identity after step (3)? Independently, based on the id_token that is evaluated on either side? Or will the client fetch additional data?

I assume URL length restrictions do not hold for fragements, otherwise there would be limitations regarding id_token/access_token size.

What is your story for existing OpenID 2.0 RP? Do you intend to propose them to migrate to the Basic profile?

regards, Torsten.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001641.html

> So the RP implementation requires a combination of backend and client side code. Furthermore, the RP needs to process two (or more? - see below) calls to perform the login. In contrast, a login based on the code flow can be implemented in the backend only and requires only a single request on the RP.

The JS for POSTing the fragment to the backend could be cached as part of the initial page load at the RP, the redirect from the Authorization endpoint would trigger the cached JS and the result would be a single POST to the RP.

The response from the post can set browser cookies, allowing a simple client less overhead in maintaining state with the backend call.

I don’t have any special personal attachment to the implicit flow, others can probably better defend it.

> In my opinion, the Basic profile is opimized from a OP perspective as it minimizes calls and (potentially) shared state on the OP’s side whereas the code flow is easier to use from a RPs perspective. >

That may depend on the RP, but point taken.

> Further questions regarding Basic profile: > How are client and server state synchronized with respect to the user identity after step (3)? Independently, based on the id_token that is evaluated on either side? Or will the client fetch additional data? >

I don’t understand the question client and server are a bit ambiguous.

In the above flow the Web Server is the client, It has a bit of JS to help relay the message and get around using a POST redirect.

I would not call the browser the client in that case.

It is possible that there are cases where you would have a canvas app in the browser that is interacting with the OAuth endpoints as well as a WebServer that is using the id_token to grant access to some of it’s resources. That is however a much more complicated case.

> I assume URL length restrictions do not hold for fragements, otherwise there would be limitations regarding id_token/access_token size. > > What is your story for existing OpenID 2.0 RP? Do you intend to propose them to migrate to the Basic profile?

Migrate to Connect, Basic if it works for them or one of the other flows if they work better.

Basic is not intended to be the bast way to implement Connect, only a proposal for the simplest with basic functionality.

John

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001618.html

John, thanks for the background. This leaves me with a major question though:

> That was the way we originally had it. Later on people thought that using the OAuth multi-response type was more OAuth friendly. > > Originally if you had the scope openid: > 1 response_type=code both code and id_token were query encoded in the response

Maybe I’m missing something, but in the “code” flow, you don’t get back an id_token in that response. You get back a code, and that code can be exchanged for an access token and an id_token, since you asked for something that includes the “openid” scope. From Standard, section 2.2.1:

code

When supplied as the value for the response_type parameter, a successful response MUST include an Authorization Code as defined in the OAuth 2.0 specification. Both successful and error responses MUST be added as parameters to the query component of the response. All tokens are returned from the Token Endpoint. Authorization Servers MUST support this response_type.

So the whole issue of query-encoding the id_token isn’t even an option here. It is an option if you’re asking for something akin to “code id_token”, but that wasn’t on the table. In the current spec, those are both defined as fragment encoded anyway.

> 2 response_type=token both access_token and id_token were fragment encoded. > > There was no way to just get code or access_token, and no way to get just id_token.

The former, yes, there is: just don’t include the “openid” scope.

The latter, no. But if you ask for a token with just the “openid” scope and don’t ask for any other permissions, the server could give you a null or empty or otherwise useless access token there, if it wanted to. I agree that if this is a real and viable use case, then it should be a separate kind of response_type, but I’m not seeing that right now.

> It was simpler I will give you that. > > It is a bit different from adding id_token to the token endpoint in that there is no OAuth mechanism for controlling the response from the endpoint. I suppose the alternative would have been to add an extra parameter to the token endpoint request to say if you wanted a id_token.

No, again, that’s what the scope already handles. If we didn’t have a standardized scope value, then I’d agree with this.

– Justin

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001619.html

> So the whole issue of query-encoding the id_token isn’t even an option here. It is an option if you’re asking for something akin to “code id_token”, but that wasn’t on the table. In the current spec, those are both defined as fragment encoded anyway.

Having id_token returned in the front channel was one of the early must haves from the major IdP. Given that in the early days we returned id_token query encoded in the front channel and from the token endpoint. It looked like a hack. There was no way to change the semantics of code. With the multi token response type change around draft 19 of OAuth I think, Google and Facebook decided that was the best way to indicate the response_type, rather than overloading the semantics of scopes.

Currently if you ask for code it is defined in the OAuth 2 core spec and you get code back just as you would expect, the same goes for token. We avoided reinterpreting the OAuth spec as much as possible. The permissible way to ask for multiple tokens is the return type and that is what we are currently doing.

> >> 2 response_type=token both access_token and id_token were fragment encoded. >> >> There was no way to just get code or access_token, and no way to get just id_token. > > The former, yes, there is: just don’t include the “openid” scope. The latter, no. But if you ask for a token with just the “openid” scope and don’t ask for any other permissions, the server could give you a null or empty or otherwise useless access token there, if it wanted to. I agree that if this is a real and viable use case, then it should be a separate kind of response_type, but I’m not seeing that right now. >

The thing is that if you don’t include the openid scope you are not doing openid Connect and our spec has nothing to say in the matter. So removing the openid scope so that the IdP can’t tell if it is a connect request or some other OAuth request is not a real option.

The only thing I might change at this point on response_type if I had a do over would be to use underscores rather than spaces to reduce confusion. Other than that I don’t think we have a problem.

In reality a client will only use a single response type appropriate for it. They are not dynamically changing these things. If you want code as a query parameter just ask for ‘code’ all the options are available to the clients without confusing it with the scopes.

>> It was simpler I will give you that. >> >> It is a bit different from adding id_token to the token endpoint in that there is no OAuth mechanism for controlling the response from the endpoint. I suppose the alternative would have been to add an extra parameter to the token endpoint request to say if you wanted a id_token. > > No, again, that’s what the scope already handles. If we didn’t have a standardized scope value, then I’d agree with this. >

Again if you remove the openid scope it is not openid. That is the scope that asks for the user_info endpoint and the user_id.

John

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001620.html

On not being OpenID: I would say that if you’re not getting an ID Token back, you’re not doing OpenID Connect, you’re just doing OAuth2. If you happen to be doing OAuth2 against something that has a User Info Endpoint, that’s fine, but it’s not binding you to the user’s session. It’s definitely the right thing to avoid mucking about with OAuth2 wherever possible.

But the question being addressed below was “how do I know when to include the ID Token?”, and I think it should break down as follows (assuming user grants access and all else is validated):

What I’m saying is that #3 above is an odd special case that could be subsumed by #4 above. This all gets rid of the need for the id_token response type entirely. Apart from being a breaking change, I don’t see how this doesn’t cover the use cases described below.

– Justin

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001621.html

The current specs have much simpler rules than the ones proposed below. They are:

  • If response_type includes id_token, return an ID Token.
  • If response_type includes token, return a Token.
  • If response_type includes code, return a Code.

These can be mixed and matched as meets the Client’s needs.

I don’t see a good reason to make it any more complicated than that.

– Mike

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001622.html

( refer to http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001620.html )

I don’t see why this is simpler. It’s actually more obscure to developers. The scope ‘openid’ refers to scope of access – namely the request to learn the user’s identifier at the issuer.

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001623.html

I agree with Breno, keeping scopes and response types separate will cause fewer problems down the road.

We have a number of new response types registered, (I may have to hurt the next person who talk about them being com posable.)

Each response_type clearly defines what is returned from the authorization server, and how it is to be returned (ignoring grey area for post message).

The openid scope makes the protocol openid asking for a authentication grant. e.g. Do you want to log into x and give them access to your user_id. Simple.

The openid protocol requires that id_token is always returned from the token endpoint when exchanging code. Simple.

The registered responstypes define what is returned from the authorization endpoint and how. Simple.

Removing some of the return_types and overloading the openid scope with more semantics is more complicated.

My opinion John B.

Note

scope=openid

  • authentication assertion - identifier user@idp is asserted.
  • standard user attributes - access token to User Info endpoint

authentiation assertion:

  • format
    • id_token
  • response

    • indirectly in URL fragment ( only if specified response_type has id_token)
    • directly from tokne endpoint

standard user attributes

  • User Info JSON

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120220/001624.html

Yes.

As I understand, OAuth’s response_type parameter tells what is to be returned by the Authorization Endpoint. We should stick to the semantics of it and should not alter it.

Perhaps we could state it in our specs, but that actually is something that OAuth spec. really should do.

FYI, I wrote a blog post with a table showing what are to be returned in each cases.

Hope this helps.

http://nat.sakimura.org/2012/02/22/the-relationship-between-endpoint-responses-and-response_type-scope-pair/

=nat

Note

response_type = what is(are in Connect) to be returned.

Mandatory-to-implement token type

http://www.ietf.org/mail-archive/web/oauth/current/msg07906.html

Stephen, as AD, brought up the question of mandatory-to-implement token types, in the IETF 82 meeting. There was some extended discussion on the point:

  • Stephen is firm in his belief that it’s necessary for interoperability. He notes that mandatory to implement is not the same as mandatory to use.
  • Several participants believe that without a mechanism for requesting or negotiating a token type, there is no value in having any type be mandatory to implement.

Stephen is happy to continue the discussion on the list, and make his point clear. In any case, there was clear consensus in the room that we should specify a mandatory-to-implement type, and that that type be bearer tokens. This would be specified in the base document, and would make a normative reference from the base doc to the bearer token doc.

We need to confirm that consensus on the mailing list, so this starts the discussion. Let’s work on resolving this over the next week or so, and moving forward:

  1. Should we specify some token type as mandatory to implement? Why or why not (briefly)?
  2. If we do specify one, which token type should it be?

Barry, as chair

Note

  • mandatory-to-implement
  • mandatory-to-use

http://www.ietf.org/mail-archive/web/oauth/current/msg07918.html

> 1. Should we specify some token type as mandatory to implement? Why > or why not (briefly)?

No, since I do not believe that the force of compliance with this one point of the spec will be enough to persuade those who don’t want to use whatever the MTI token type ends up being to use it. Let’s say that we were to pick Bearer, but Example.com decides to only support MAC for their API. Is it correct to say that Example.com is not really doing OAuth2? I would argue no, since they’re doing everything within spec to issue tokens, and the tokens that they’re issuing are well defined and within spec as well. So then let’s say, hypothetically, that in order comply with the letter of the law, they implement a Bearer token as well as MAC. But which type do they issue to clients? Clients have no way of choosing or discovering which what kind of token comes back (yet). If Bearer is MTI, how do you even use another token type?

Which brings us to MTI in clients, [2] which makes even less sense. Let’s say that I’m writing a client to talk to Example.com, which hands back MAC tokens. I want to comply with the spec, so I implement Bearer support in my client, code paths which will never see the light of day.

Then there’s the argument that a generic library is what’s really meant by “client” here, and that those MUST follow the MTI guidelines. I also find this to be ludicrous, since client libraries will implement whatever servers support. A good client library will support both MAC and Bearer together, along with whatever magical tokens that haven’t been dreamed up yet that are getting traction.

Ultimately, I think that our declaring something MTI is a position of hubris that won’t affect how people really use this thing.

– Justin

http://www.ietf.org/mail-archive/web/oauth/current/msg07921.html

[2]: refered.

I think this is really the key problem. To date, there isn’t a unified library that clients and servers are using that could force this issue: every server/site is rolling their own oauth sdk, and they don’t have much reason now to change that. If/when something emerged as being the oauth equivalent of openssl, then it would make sense to tighten requirements on such a library to achieve better interoperability. It would also coincide with actual real world _knowledge_ of what the appropriate MUST-IMPLEMENT’s are instead of guessing. All a mandatory requirement will do now is alienate a lot implementations who are otherwise striving to be compliant.

So my bottom line to Stephen: defer this to a later recycle of the rfc.

Mike

http://www.ietf.org/mail-archive/web/oauth/current/msg07923.html

> 1. Should we specify some token type as mandatory to implement? Why or > why not (briefly)?

On the server - no. It makes no sense because the server dictates the token type so if it decides to never issue the mandated type, what’s the point in implementing?

On the client, maybe. If the server knows that a client will always understand a set of token types, it can choose to use that and ensure interop (or not). In practice, mandating will add no real interop value. Almost every client will hard-code the token types it needs to understand and providers are not likely to support more than one or to change it. We can mandate a type for ‘generic clients’ so that libraries support both, but it won’t actually make any difference.

Bottom line, this is a red herring. OAuth doesn’t really provide this level of interop and was never designed for that. In the future, when we have more interop web APIs (photos, social, etc.) and we have real world experience with discovery, this will be important. But that’s a few years away (at least).

> 2. If we do specify one, which token type should it be?

This is a no win situation. Most providers will ignore a requirement to support MAC, or will support it but will not see much usage because most developers when given the choice will go with Bearer. Mandating Bearer will be ignored by providers who want better security and will most likely render MAC pointless. If we mandate Bearer, I see no point in even publishing MAC as it will turn into a purely theoretical exercise.

Given the history of this group, no change is the only likely consensus.

EHL

http://www.ietf.org/mail-archive/web/oauth/current/msg07973.html

Re: “So, pick one (my strong personal preference) or establish and document why you’re not picking one seem to me to be the choices available.”

We don’t have discovery done (enough) yet to lean on it in the core spec, but if we did I’d be in favor of something that says that you must implement either an MTI token OR a discovery mechanism that advertises at least one token. Would that be workable?

We could bang on the discovery stuff in pretty short order I think if we needed to.

-bill

«  Resource   ::   Contents   ::   Decoupling Identity and Authentication  »