Can OAuth 2.0 support multiple grants in a single redirection journey?

My question is pretty simple:

If you have two web-application components:

1. Server-side (secret-capable) code in PHP, Python, Perl ... whatever
2. The javascript output and interpreted by the browser

Given a single redirection to the authorisation endpoint (and back) is it possible to specify and transfer the information for:

1. An authorization code grant (for the server-side code)
2. An implicit grant with restricted rights for the Javascript

thereby transferring the two grants (one in the request-url proper and the other in the fragment) in one round-trip without violating the RFC?

One redirect-loop seems c开发者_如何学编程leaner than one for each grant (even if the second doesn't block due to previous authorization)

Thanks in advance!

References

1. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-16#section-4.2

edit 1: code_and_token seems to be the type of thing I am after ... an auth code grant for the server to request the access code using its credentials ... and an implicit token for the javascript. As mov matake mentions, it was pulled from the RFC after v11, with no real note as to why. Facebook and Google seem to support this which makes me suspect it will return.

The token_and_code request type was removed from the specification because it needed significant work in terms of security analysis and rules, and no one offered to do it. It was originally proposed by a Twitter engineer who left the working group shortly after.

It will not be added to the specification, but it can easily be introduced by an extension. Google supported this flow on the list, but later said they will not implement it, and instead, will implement something else using HTML5 features.

OAuth 2.0 had "code_and_token" response type before (might be "token_and_code"). But it had been removed from the spec later.

So in current spec, if you need code for your server, the way will be

• use "code" response type
• get an access token on server side
• and give it to the client side

You can't get scope-restricted token only for client side though.. Or you might set up an proxy on your server side for your client side code.

http://www.ietf.org/mail-archive/web/oauth/current/msg04969.html and http://www.ietf.org/mail-archive/web/oauth/current/msg03655.html

says that the "code_and_token" type was good, but the RFC didn't make it clear enough that the token in the fragment (for Javascript) should/could have less rights than the token obtained by the access code...

Thanks Nov Matake for pointing out the code_and_token type was part of the spec (at one point) as I missed it in the old specification versions (though it is widely implemented).

Looks like it will make a comeback though, as it is quite well supported by existing implementations at Google and Facebook and seems to be a core request to support both user-agent tokens and server-side access codes in one round trip.

The problem seems to be defining the semantics of "scope" in this context as well as defining a degree to which scope can differ in a single request. It makes sense that the user-agent token has limited rights, ie not the same rights as the client application.

We shall wait and see ... the downside of implementing off the back of an involving RFC.