-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
error_response_missing_openid_scope #210
error_response_missing_openid_scope #210
Conversation
Hi, |
I added a reference to CIBA error handling |
|
||
If "openid" is missing in the scope value but a claim that is [standardized in OIDC](https://openid.net/specs/openid-connect-core-1_0.html#Claims) is requested, then the Authorization Server returns an HTTP response code of 400 (Bad Request) and an error invalid_request. | ||
For OIDC please refer to [OIDC Authentication Error Response](https://openid.net/specs/openid-connect-core-1_0.html#AuthError). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For OIDC please refer to [OIDC Authentication Error Response](https://openid.net/specs/openid-connect-core-1_0.html#AuthError). | |
For the Authorization Code Flow please refer to [OIDC Authentication Error Response](https://openid.net/specs/openid-connect-core-1_0.html#AuthError). |
We can say Authorization Code Flow instead of OIDC. CIBA is also OpenId Connect. And the link points to section 3.1.2.6. Authentication Error Response
of the OIDC Core standard which is under section 3.1. Authentication using the Authorization Code Flow
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think CIBA is not OIDC (OpenId Connect). They are separate standards published by the OIDF.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, of course, it is indeed a separate standard. What I mean is that it is called "OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0", so it looks better (or at least helpful) to me to explicitly mention the Authorization Code Flow instead of OIDC in this case, to avoid misunderstandings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But in any case, I don't think it's a big deal, so I've given my approval.
Co-authored-by: Jesús Peña García-Oliva <jesus.penagarcia-oliva@telefonica.com>
Co-authored-by: Jesús Peña García-Oliva <jesus.penagarcia-oliva@telefonica.com>
I think the text is now clear about CIBA and OIDC authoritzation code flow, thus adressing @sebdewet 's comment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a question about the access_denied, is the answer is given on the /authorize call if consent is denied by the end-user, or on the /token call ?
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
Error responses should be returned through the redirect_url if the redirect_url is valid.
Only if the redirect_url is not valid are HTTP response codes used.
Which issue(s) this PR fixes:
Fixes #209