[Federation] request authentication at other endpoints
Request authentication can be performed by means of the following, too.
CIBA (Client-Initiated Backchannel Authentication)
- Client authentication methods at the backchannel authentication endpoint; The backchannel authentication endpoint always requires client authentication. (In other words, “public” clients cannot use CIBA.)
- Request object passed to the backchannel authentication endpoint (CIBA Core Section 7.1.1); Use of request object is optional, but the FAPI-CIBA profile requires it.
Device Flow (RFC 8628)
- Client authentication methods at the device authorization endpoint; Client authentication is required only when the client type is “confidential”.
The explanation and example about request_authentication_methods_supported
in Section 4.2 OP Metadata of OpenID Connect Federation 1.0 should be updated to make sure that they don’t conflict with request authentication methods at the backchannel authentication endpoint and the device authorization endpoint listed above.
One concern is that the example value of request_authentication_methods_supported
uses ar
and par
for the authorization endpoint and the pushed authorization request endpoint like below.
"request_authentication_methods_supported": {
"ar": [
"request_object"
],
"par": [
"private_key_jwt",
"self_signed_tls_client_auth"
]
}
Because a rule on how to shorten endpoint names is not defined, sooner or later, we’ll have to discuss how to shorten names of “backchannel authentication endpoint” and “device authorization endpoint”.
Considering forward compatibility into account, official names (such as ones registered in the OAuth Authorization Server Metadata section in the IANA OAuth Parameters registry) should be used like below.
"request_authentication_methods_supported": {
"authorization_endpoint": [
"request_object"
],
"pushed_authorization_request_endpoint": [
"request_object",
"private_key_jwt",
"tls_client_auth",
"self_signed_tls_client_auth"
],
"backchannel_authentication_endpoint": [
"request_object",
"private_key_jwt",
"tls_client_auth",
"self_signed_tls_client_auth"
],
"device_authorization_endpoint": [
"private_key_jwt",
"tls_client_auth",
"self_signed_tls_client_auth"
]
}
Comments (7)
-
-
-
assigned issue to
I’ll create a PR changing the names to the officially registered ones.
@Roland Hedberg and @peppelinux_unical, do we also want to mention CIBA and the Device Flow? Given the potential security issues, I’m not prone to recommend them. At most, we could say that other authentication methods are possible, such as CIBA and the Device Flow. What do you think?
-
assigned issue to
-
Considering Takahiko’s suggestion within a non-normative example we offer a recognizable and expendable example for implementors.
We could say that other authentication methods are possible, if recognizable according to established standards and not in conflict with the operating principles behind this (Federation 1.0) specification.
I agree to use official names rather than acronyms and abbreviations. Rather than redefining names and meanings contained within well-known standards, I think it’s appropriate to create a generic pointer for present, past and future OAuth2 and OIDC specifications,
-
I’m fine with using official registered names.
I also like the wording about 'other authentication methods … “
-
- changed status to open
OK - I'll create a PR to use the authoritative names.
-
@Michael Jones I don't want to steal your task but just give an hand
Here the PR, consider necessary a revision on the language and any other indications, as you would have been the author of the PR, in the form of comment on the PR
https://bitbucket.org/openid/connect/pull-requests/219/fix-federation -
- changed status to resolved
- Log in to comment
I agree with using the officially registered names, rather than trying to shorten them.