Clear and concise description of the problem
Basically duplicate the support for scopes like for OAuth2Auth.
The example here: https://swagger.io/docs/specification/v3_0/authentication/openid-connect-discovery/ has scopes in the security: bit. It'd be great if this was also available from TypeSpec.
So I could do this:
model oidc<Scopes extends string[]>
is OpenIdConnectAuth<
"https://example.org/.well-known/openid-configuration",
Scopes
>;https://spec.openapis.org/oas/v3.1.1.html 4.8.30.1 writes: "If the security scheme is of type "oauth2" or "openIdConnect", then the value is a list of scope names required for the execution, and the list MAY be empty if authorization does not require a specified scope. For other security scheme types, the array MAY contain a list of role names which are required for the execution, but are not otherwise defined or exchanged in-band."
And maybe immediately make the scopes some map type, so we can have descriptions.
My current reading of the specs suggests that the top level "security" object should be a full collection of all scopes defined on all other parts of the API and should not have the openid scope given the examples available on the internet. But the spec doesn't say anything about it. And I never see the offline_access scope listed either, maybe those are implicit.
Checklist
Clear and concise description of the problem
Basically duplicate the support for scopes like for OAuth2Auth.
The example here: https://swagger.io/docs/specification/v3_0/authentication/openid-connect-discovery/ has scopes in the
security:bit. It'd be great if this was also available from TypeSpec.So I could do this:
https://spec.openapis.org/oas/v3.1.1.html 4.8.30.1 writes: "If the security scheme is of type "oauth2" or "openIdConnect", then the value is a list of scope names required for the execution, and the list MAY be empty if authorization does not require a specified scope. For other security scheme types, the array MAY contain a list of role names which are required for the execution, but are not otherwise defined or exchanged in-band."
And maybe immediately make the scopes some map type, so we can have descriptions.
My current reading of the specs suggests that the top level "security" object should be a full collection of all scopes defined on all other parts of the API and should not have the
openidscope given the examples available on the internet. But the spec doesn't say anything about it. And I never see theoffline_accessscope listed either, maybe those are implicit.Checklist