wrt section 4.1.3
The redirect_uri parameter should at least be required if the authz
server sent the authorization code to a redirect_uri passed in by the
client into the authorization request.
In this case, the authorization server must bind this uri to the authz
code and require the client
It's easiest to remember that the redirect_uri in a access token request
must be an exact match as the one passed into the auth code request
If the pre-registered redirect_uri is http://foo.com/authed
an authorization code request's redirect_uri may be
http://foo.com/authed/bar
In the access
Did a full read through of draft 16 and the bear token spec with Paul
yesterday afternoon in order to do a manual diff from draft 10. The
point Doug raised was actually confusing. Throughout the core spec
it's referred to as access_token but then becomes bearer_token upon
use.
Just thinking
In sections 4.1.3, 4.3.2, 4.4.2 and 6 there's a list of parameters
included within the request and then the sentence, The client
includes its authentication credentials as described in Section 3.
Reading through the spec yesterday afternoon with Paul, we first
thought that client_secret was
-Doug Tangren
http://lessis.me
On Sat, May 28, 2011 at 12:30 PM, David Recordon record...@gmail.comwrote:
Did a full read through of draft 16 and the bear token spec with Paul
yesterday afternoon in order to do a manual diff from draft 10. The
point Doug raised was actually confusing.
Facebook accepts both access_token and oauth_token today but only
documents access_token. I imagine we'll continue doing the same with
bearer_token until it gets sorted out a bit more. Thus we'd document
access_token but note that oauth_token and bearer_token will also
work. :-\
On Sat, May 28,
I just re-read draft 16 on this memorial day weekend :)
1. I had a comment on the suggested use of the authorization code flow for
native clients [1].
Section 10.9 on auth code transmission [2] suggests users of the auth code
flow should implement tls on it's redirect uri. This makes sense for
