[Openid-specs-ab] Discussion on cookies

[Breno de Medeiros]

Note: Openid-specs-ab is in the BCC because it's a closed post group.
Please add it to your recipient list if you want to copy the group
(and have post privileges).

We discussed several possibilities for adding a session token or
cookie to the OpenIDConnect flow. The main concern here is for the
UserAgent flow, since it has stronger restrictions on how to issue
tokens.

Hybrid Compatibility Requirement: That it be possible to
simultaneously obtain authentication tokens and authorization to
access user's data (as in OpenID+OAuth hybrid and FBConnect).

Points of general agreement: The cookie is a signed JWT, with fields
for user id, issuer, and audience.

Possibility #1: The JWT/cookie/session token  _is_ the access token
Assessment: This is undesirable for hybrid compatibility reasons,
mandating token formats for all APIs, where OAuth2 uses opaque tokens.
Conclusion: Thumbs down

Possibility #2: The JWT/cookie/session token contains the access token
as a field
Assessment: It was speculated that this may raise security concerns in
some application scenarios. For instance, consider Simple App that
uses only sign-on and access to friend information for viral growth,
but does not actually exposed any API to the user that allows to
interact with friends data. In this case, if the session cookie is
compromised (e.g., Simple App does not support TLS), only the user's
data at Simple App is compromised. However, if the session cookie
includes a reference to the access token, then user's friend
information at the provider might leak.
Conclusion: Circulate proposal in this list for further feedback

Possibility #3: The JWT/cookie/session token contains some claim about
the access token as a field, where the claim only asserts a hashed
digest of the access token
Assessment: Possibly over-engineered?
Conclusion: Circulate proposal in this list for further feedback

Possibility #4: The JWT/cookie/session token contains no reference to
access token
Assessment: This creates a substantial risk that 3rd parties will not
perform any checks as to whether the two tokens are bound to the same
user+audience pair. Moreover, the only way to check this is
essentially to make a call to the UserInfo endpoint and repeating the
same type of checks for the cookie (audience, user_id) that are
mandated for the cookie.
Conclusion: Double validation feels like a hack and probably will not
be done correctly. Likely reject, but forward to this list for further
feedback

Possibility #5: The UserInfo endpoint returns a cookie.
Assessment: Does that confuse the mission of the user info endpoint,
from being an OAuth2 protected resource that returns information about
the user into a token swap endpoint? Or is the UserInfo endpoint
mission so much entangled with authentication already (e.g., audience
is not a user attribute, but would be returned by the U.I. endpoint)
that it's okay to add this functionality there?
Conclusion: Extend the discussion via email to this list for further feedback

Possibility #6: Make a call to the/a token swap endpoint to get a
cookie based on the access token.
Assessment: Don't remember
Conclusion: Extend the discussion via email to this list