Skip to content

No possibility currently to specify grant-type ciba in OAS #3587

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

Closed
shilpa-padgaonkar opened this issue Feb 17, 2024 · 6 comments
Closed

No possibility currently to specify grant-type ciba in OAS #3587

shilpa-padgaonkar opened this issue Feb 17, 2024 · 6 comments
Assignees
Labels
security: auth Authentication including overlap with authorization security
Milestone

Comments

@shilpa-padgaonkar
Copy link
Contributor

shilpa-padgaonkar commented Feb 17, 2024

Camara APIs use the grant type CIBA https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.10.1 and currently have no way to specify it in our OAS files. Could the specification be extended to support the CIBA grant type?

@handrews handrews added security: auth Authentication including overlap with authorization security labels Feb 18, 2024
@karenetheridge
Copy link
Member

Are you referring to the type field in the security scheme object (https://spec.openapis.org/oas/v3.1.0#security-scheme-object)?

I wonder if this field should not be limited by an enum -- the existing supported schemes can have further support in the spec, but allowing any string here would allow for users to make extensions in their own implementations. Or would that potentially break forward compatibility?

@LasneF
Copy link
Member

LasneF commented Feb 22, 2024

@karenetheridge , Regarding the support of ciba and introducing a new type , i think adding a new one would be not really a good idea,
CIBA is more a flavour of OIDC , that can be supported or not. i wonder if we should not add a flag (this is the same for the PKCE support for instance in Oauth2 )

the issue would be that it create a kind of depedency between the OAS spec and the security spec , as the list of flavour can grow not in synch with OAS

i wonder if we should not add an field flavours , that is an array of string , so that we can push Ciba and more

if we want to be normative , it could provide the URI of the flavour in this array

CIBA is one of them but looking on FAPI 2 , the flavours keep growing https://oauth.net/fapi/

@shilpa-padgaonkar
Copy link
Contributor Author

@LasneF, CIBA is a grant type just like authorization_code. It is not an OIDC flavour.

@shilpa-padgaonkar
Copy link
Contributor Author

@karenetheridge, No, I am referring to the flows field

@LasneF
Copy link
Member

LasneF commented Feb 26, 2024

@karenetheridge in fact the point you mentionned is valid , and raise questions about how the security scheme in OAS is describe.

meaning ciba is not just a grant type but an entire flow , should it be defines inside Oauth2 ?, it could as the other flow

but considering that ciba grant type urn:openid:params:grant-type:ciba
ciba is part of OIDC as an optional feature (this is what i was calling flavour) , it could be considered that it will be describe via the OIDC url in the configuration endpoint in the grant_type_supported field

those are kind of in the middle

notice that device code flow could be added too (here as part of Oauth)

to me you are raising the capability of discovering the feature supported by a security scheme and the limit OIDC / Oauth2
OIDC has a nice mechanism for it via openid-configuration
that is the best for OAS as it is decoupling it from the OIDC spec , but in mean time relying on a URL could be considered as too dynamic . and does not provide quickly a few of what is supported or not and even more precisely for this particular endpoint

it make it quite challenging for OAS to follow

the request is very valid you want to advertise CIBA flow is supported
the answer adding it in Oauth2 works even if Ciba is more an OIDC defined artefact
then for OAS it s a challenge knowing than on OIDC there are plenty of flavors , around the JWT content , the flows supported ,
and to me even the discovery URL is not 100 % satisfying

@miqui
Copy link
Contributor

miqui commented Feb 29, 2024

@shilpa-padgaonkar - TODO: create a new PR describing the grant type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security: auth Authentication including overlap with authorization security
Projects
None yet
Development

No branches or pull requests

5 participants