From section 3.1.2.1 of the OpenID Connect Core...
scope
REQUIRED. OpenID Connect requests MUST contain theopenidscope value.
*If the****openid****scope value is not present, the behavior is
entirely unspecified.* Other scope values MAY be present. Scope
values used that are not understood by an implementation SHOULD be
ignored. See Sections5.4
<http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims>and11
<http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess>for
additional scope values defined by this specification.
In this light, there is no specification that covers the behavior of the
AS given the authorization request you provided.
At least that is my reading of the specs.
Thanks,
George
On 6/26/17 1:59 PM, Takahiko Kawasaki wrote:
Thank you. Please let me ask a simplified question.
If an authorization server returns this response (including id_token):
HTTP/1.1 302 Found Location: https://client.example.org/cb#
access_token=SlAV32hkKG &token_type=bearer &id_token=eyJ0 ...
NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso &expires_in=3600
&state=af0ifjsldkj
when it receives this request (without scope=openid):
GET /authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org
<http://2Fclient.example.org>%2Fcb
&state=af0ifjsldkj HTTP/1.1
Host:server.example.com <http://server.example.com>
, is the implementation of the authorization server correct?
Best Regards,
Takahiko Kawasaki
2017-06-26 21:53 GMT+09:00 Philippe Signoret
<[email protected]
<mailto:[email protected]>>:
None of the examples in that spec are _/OpenID Connect/_
authentication requests. They are, however, valid _/OAuth 2.0//_/
authorization requests. The one in question demonstrates use of
the response_mode=id_token, as defined in the realm of OAuth 2.0.
If (and only if) it had scope=openid, _/then/_ it would become an
OpenID Connect auth request, and the OpenID Connect specs would
apply.
In other words, the fact that id_token is in the response_type
does _/not//_ /automatically make it an OpenID Connect request.
Another way of seeing it is that the OAuth 2.0 Multiple Response
Type Encoding spec is laying some foundations, as part of the
OAuth 2.0 framework, upon which OpenID Connect is then built.
In Section 11.3. OAuth Authorization Endpoint Response Types
Registry <https://tools.ietf.org/html/rfc6749#section-11.3>, the
OAuth 2.0 spec (RFC 6749) defines a registry of response types:
This specification establishes the OAuth Authorization Endpoint
Response Types registry.
Then, in Section 3, ID Token Response Type
<http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#id_token>,
OAuth 2.0 Multiple Response Types registers “id_token” as a
response type in that same registry:
This section registers a new Response Type, theid_token, in
accordance with the stipulations in the OAuth 2.0 specification,
Section 8.4. The intended purpose of theid_tokenis that it MUST
provide an assertion of the identity of the Resource Owner as
understood by the Authorization Server. The assertion MUST specify
a targeted audience, e.g. the requesting Client. However, the
specific semantics of the assertion and how it can be validated
are not specified in this document.
Finally, on that OAuth 2.0 foundation, the OpenID Connect spec
defines (amongst other things) that including “scope=openid” is
how the client indicates that this is an OpenID Connect request,
makes use of the previously registered Response Type “id_token”
(in some flows—other flows don’t use the “id_token” response
type), and proceeds to specify the format and contents of the ID
Token:
OpenID Connect implements authentication as an extension to the
OAuth 2.0 authorization process. Use of this extension is
requested by Clients by including theopenidscope value in the
Authorization Request. Information about the authentication
performed is returned in a*JSON Web Token (JWT)*
<http://openid.net/specs/openid-connect-core-1_0.html#JWT>[JWT]
called an ID Token (see*Section 2*
<http://openid.net/specs/openid-connect-core-1_0.html#IDToken>).
Philippe
*From:*Takahiko Kawasaki [mailto:[email protected]
<mailto:[email protected]>]
*Sent:* Monday, June 26, 2017 2:17 PM
*To:* Philippe Signoret <[email protected]
<mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>
*Subject:* Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response
Type Encoding Practices
The response_type of the example includes id_token and it is the
reason I've brought it up. id_token triggers Authentication Request.
# The response_type in the example in Appendix A
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Foauth-v2-multiple-response-types-1_0.html%23FragmentExample&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C092adcaef9954edf8e3208d4bc8d2fba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340761951990482&sdata=mRz8ViYA0cYXXO4iVw1vAgO4Xejh%2FDcxYegTfdeOSBw%3D&reserved=0>
does not include id_token and so I've not mentioned it.
Best,
Taka
2017-06-26 17:09 GMT+09:00 Philippe Signoret
<[email protected]
<mailto:[email protected]>>:
scope=openidis required for OpenID Connect Authentication
Requests (e.g. "3.3.2.1. Authentication Request
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23HybridAuthRequest&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=HO6gAigTdBjgxOhsS41bKLbbl1cUyUugvXBjJ4hwmKE%3D&reserved=0>"
in "OpenID Connect Core 1.0
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=FrFLKpyHVfZbRw1OsOs7QH%2F2bSrJbJluKnny0X%2FiJxw%3D&reserved=0>"),
but not for an OAuth 2.0 Authorization Request (e.g. "4.1.1.
Authorization Request
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6749%23section-4.1.1&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C092adcaef9954edf8e3208d4bc8d2fba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340761952000490&sdata=%2FHh3%2BtauyK%2F03OVtSOX7p8XpidnT%2FPGHq8cwvl07vwg%3D&reserved=0>"
in "RFC6749 The OAuth 2.0 Authorization Framework
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6749&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C092adcaef9954edf8e3208d4bc8d2fba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340761952000490&sdata=a0%2BsS06wPx%2FxzxKc6z7pBXnQ0p4V7yciycZ%2F6uKJ2SU%3D&reserved=0>").
OpenID Connect is “an identity layer on top of the OAuth 2.0
protocol”. OpenID Connect specs will often refer to aspects of
the OAuth 2.0 protocol, but the OAuth 2.0 specs will generally
not refer to the OpenID Connect constructs. (Because OpenID
Connect is a specific case of OAuth 2.0.)
Philippe
*From:*OAuth [mailto:[email protected]
<mailto:[email protected]>] *On Behalf Of *Takahiko Kawasaki
*Sent:* Monday, June 26, 2017 7:46 AM
*To:* [email protected] <mailto:[email protected]>
*Subject:* [OAUTH-WG] Example in OAuth 2.0 Multiple Response
Type Encoding Practices
Hello,
I'm not so sure that this is the right place to ask, but I'm
wondering whether it is correct or not that the following
non-normative example found in "5. Definitions of Multi-Valued
Response Type Combinations
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Foauth-v2-multiple-response-types-1_0.html%23Combinations&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=A2%2F5R%2FFDSMUN8lthoex%2BAnF3h%2FouQHjXBPhW3Yv5D7M%3D&reserved=0>"
in "OAuth 2.0 Multiple Response Type Encoding Practices
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Foauth-v2-multiple-response-types-1_0.html&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=oax1ui3n46P2n67Mqx14t0458TZjrcw9IUsdCoGsmho%3D&reserved=0>"
does not include "scope=openid".
GET /authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F2Fclient.example.org&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=%2BaCAvhV9qt75Cqajdrr84BVG6MRS3747Ux5CsjJtgQE%3D&reserved=0>%2Fcb
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fserver.example.com&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=PoXzHooKqVnYx4pzWD%2B4THUElRZjsUC2TNdMlTrhfiY%3D&reserved=0>
The reason I'm wondering is that "3.3.2.1. Authentication
Request
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23HybridAuthRequest&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=HO6gAigTdBjgxOhsS41bKLbbl1cUyUugvXBjJ4hwmKE%3D&reserved=0>"
in "OpenID Connect Core 1.0
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=FrFLKpyHVfZbRw1OsOs7QH%2F2bSrJbJluKnny0X%2FiJxw%3D&reserved=0>"
requires Authentication Requests be made as defined in
"3.1.2.1. Authentication Request
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23AuthRequest&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=WoKMDXrFJDmvaGHGY8ry8Nn7iG5qliNjqNw8UamnHHg%3D&reserved=0>"
and "3.1.2.1" requires the scope request parameter contain openid.
Best Regards,
Takahiko Kawasaki
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
