[Openid-specs-ab] Question about prompt=none
daru.tk at gmail.com
Thu Jan 7 18:22:23 UTC 2016
Dear Torsten, John, Justin,
Thank you very much for your valuable comments. It seems there is an
undocumented but shared assumption that prompt=none expects authorization
servers have a mechanism to remember previous grants and reuse them. I now
think that if an AS implementation does not have such a mechanism, it
should avoid issuing tokens (authorization codes, access tokens and ID
tokens) when an authorization request comes with prompt=none.
2016-01-03 5:56 GMT+09:00 Justin Richer <jricher at mit.edu>:
> John, you’re technically correct that it’s “OAuth not OIDC” but you’re
> ignoring the fact that most OIDC implementations are built upon standalone
> OAuth systems which continue to offer basic OAuth functionality as well. In
> our implementation at least, the processing of the “prompt” parameter is
> handled the same way for all requests regardless of whether or not the
> “openid” scope was used. I doubt our method of processing these parameters
> is uncommon.
> But this still isn’t a security problem. What “prompt=none” means is that
> the AS can only say “yes” or “you need to ask the user”. The cases where it
> can say “yes” are limited to those where the user would not have been
> prompted anyway. Namely, the user already has authorized the client for the
> scopes being requested, or the client is whitelisted, or some other
> consideration like that. If there’s anything that would cause user
> interaction, including a login, then the response returns with “you need to
> go ask the user”. This is fine for both OIDC and OAuth transactions.
> What wouldn’t be fine is if the server needed to display something to the
> user, even a notification, in the normal case but it turned off that
> functionality for the “prompt=none” request. That’s not what’s being asked
> for in the protocol, though.
> — Justin
> > On Jan 1, 2016, at 2:02 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> > If the request doesn’t contain the openid scope then it is not OpenID
> Connect, it is just OAuth.
> > So there is no case where a client could do connect and not request any
> > Many sites remember authorization grants the user has consented to for a
> particular site, and don’t re-prompt the user for consent each time.
> > If a request with prompt=none arrives and the client is asking for
> scopes that the user previously consented to including checking remember
> this in the UI, then
> > a code with those grants can be returned.
> > In the case of OAuth asking for no scopes then the server would generate
> an error unless it is configured with some default scope.
> > I guess you could generate code and AT with no scopes attached but that
> would be sort of strange.
> > John B.
> >> On Jan 1, 2016, at 12:09 PM, Takahiko Kawasaki <daru.tk at gmail.com>
> >> Dear All,
> >> I have a question about prompt=none which is defined in "OpenID Connect
> Core 1.0, 22.214.171.124. Authentication Request".
> >> The description in the specification says as follows:
> >> The Authorization Server MUST NOT display any authentication or
> >> consent user interface pages. An error is returned if an End-User
> >> is not already authenticated or the Client does not have pre-
> >> configured consent for the requested Claims or does not fulfill
> >> other conditions for processing the request. The error code will
> >> typically be login_required, interaction_required, or another
> >> code defined in Section 126.96.36.199. This can be used as a method to
> >> check for existing authentication and/or consent.
> >> If an End-User is already authenticated and the Client does not request
> any claim (e.g. does not request an ID token), is it allowed to issue an
> authorization code and/or an access token? For example, if a request comes
> with prompt=none and response_type=code (and other necessary parameters),
> is it allowed to issue an authorization code without any interaction with
> the End-User? Doesn't this cause a security issue? What happens if an
> End-User who has already logged in a certain SNS and he loads a malicious
> HTML that makes a request to the SNS with prompt=none and
> response_type=code behind the scenes without letting him know the request?
> >> What use case justifies prompt=none? It is difficult for my poor
> imagination to make up a secure use case of prompt=none (except the case of
> response_type=none) unless there are undocumented conditions (e.g. an
> out-of-band consent prior to a request). What were discussed in WG about
> >> If an implementation of authorization server does not provide any means
> for End-Users to set "pre-configured consent" (188.8.131.52. Authentication
> Request) for claims and does not provide other out-of-band consent for
> issuing authorization codes and access tokens, I guess that the
> implementation cannot help but reject any request with prompt=none unless
> it comes with response_type=none. What do you think?
> >> Best Regards,
> >> Takahiko Kawasaki
> >> _______________________________________________
> >> Openid-specs-ab mailing list
> >> Openid-specs-ab at lists.openid.net
> >> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab