[Openid-specs-ab] Lite Draft 9
John Bradley
ve7jtb at ve7jtb.com
Fri Aug 19 19:12:57 UTC 2011
The id_token is the access token for the check session endpoint.
Only the id_token is sent to the check session endpoint.
As Oauth only has one access token we have to give the access token for the session endpoints a separate name. That is id_token. I did rase the possibility of calling it session but no one took me up on that.
The access token for the check session endpoint is a signed JWT that way a client can inspect it directly and never use the check session endpoint.
John B.
On 2011-08-19, at 3:06 PM, Allen Tom wrote:
> In section 3.3.1 - Are both the access_token and the id_token supposed to be sent to the Check Session endpoint? The way that Section 3.3.1 in Draft 9 is currently written, it sounds like only the id_token is sent in the request, and that the id_token is actually the access_token.
>
> It would probably be helpful to have an example Check Session request in the spec.
>
> Allen
>
>
> On Fri, Aug 19, 2011 at 12:02 PM, Allen Tom <allentomdude at gmail.com> wrote:
> The explanation in Section 3 regarding when to use the Implicit vs Code flow is vague, because it's not clear as to what it means for a client to securely maintain state between itself and the auth server.
>
> It might be better to just say that the Code flow should be used if the redirect_uri doesn't use HTTPS, and if the client is able to securely store its client_secret.
>
> Allen
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110819/4fed50e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110819/4fed50e4/attachment.p7s>
More information about the Openid-specs-ab
mailing list