You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Detta är en kopia av en issue jag skapade för Sweden Connect Tekniskt ramverk (swedenconnect/technical-framework#191). Som det ser ut så kommer vi inte att speca OAuth2 under Sweden Connect utan istället via ENA. Därför är detta relevant här ...
Currently, Sweden Connect provides specifications regulating authentication and federated signing. The roadmap also includes extending the authentication specifications with profiles for OpenID Connect. Authorization and delegated rights have so far been out of scope for the Sweden Connect specifications.
The lack of a national profile for how to handle authorization and delegation has led to a number of solutions where proxy SAML-IdP:s are used to issue assertions containing both identity attributes and role information. Also, SAML-assertions are passed around between services as "proof" of a logged in user. And perhaps the worst thing, user data is shared among services with no involvement or knowledge of the user (that owns the data). These homemade attempts to solve some of the issues that arise concerning authorization and delegation falls under "driving in a nail using a screwdriver", i.e., using the wrong tool to solve the problem.
So, which areas do we need to address in a standardized fashion?
For a Resource Server*:
Centralized support for authentication and authorization of calling entities, i.e., how shall a resource server authenticate and authorize calls to it?
Before delivering the user's data in a response message the Resource Server needs proof of the user's consent to do so.
Extending the previous item: The Resource Server requires proof of that the calling entity has the user "logged in" before delivering user owned data to the calling entity.
[*]: We define a Resource server to be an entity (service) that in some way service's a user's data, for example an API-server that delivers data owned/belonging to a user or a web site that presents the user's data.
Other areas:
We need standardized ways to handle user-to-user delegation (and/or impersonation). For example, user A gives user B rights to represent him or her (for a given service).
Easier setup of services is required. A centralized "metadata" service holding the registration data for authorization servers, clients and possibly also resource servers will be needed. This repository will hold keys, adresses and relevant registration metadata.
Suggestion
The Sweden Connect technical specifications are extended with support for authorization and delegation, with profiles/specs covering:
An OAuth 2 interoperability profile.
Attribute (claims) definitions.
A Token Exchange profile.
Representations of "ID tokens" as part of an JWT access token.
Specifications for client authentication.
Registration requirements (metadata).
Resources
This section lists documents that we should look into and extend/specialize during the work:
Detta är en kopia av en issue jag skapade för Sweden Connect Tekniskt ramverk (swedenconnect/technical-framework#191). Som det ser ut så kommer vi inte att speca OAuth2 under Sweden Connect utan istället via ENA. Därför är detta relevant här ...
Currently, Sweden Connect provides specifications regulating authentication and federated signing. The roadmap also includes extending the authentication specifications with profiles for OpenID Connect. Authorization and delegated rights have so far been out of scope for the Sweden Connect specifications.
The lack of a national profile for how to handle authorization and delegation has led to a number of solutions where proxy SAML-IdP:s are used to issue assertions containing both identity attributes and role information. Also, SAML-assertions are passed around between services as "proof" of a logged in user. And perhaps the worst thing, user data is shared among services with no involvement or knowledge of the user (that owns the data). These homemade attempts to solve some of the issues that arise concerning authorization and delegation falls under "driving in a nail using a screwdriver", i.e., using the wrong tool to solve the problem.
So, which areas do we need to address in a standardized fashion?
For a Resource Server*:
Other areas:
We need standardized ways to handle user-to-user delegation (and/or impersonation). For example, user A gives user B rights to represent him or her (for a given service).
Easier setup of services is required. A centralized "metadata" service holding the registration data for authorization servers, clients and possibly also resource servers will be needed. This repository will hold keys, adresses and relevant registration metadata.
Suggestion
The Sweden Connect technical specifications are extended with support for authorization and delegation, with profiles/specs covering:
An OAuth 2 interoperability profile.
Attribute (claims) definitions.
A Token Exchange profile.
Representations of "ID tokens" as part of an JWT access token.
Specifications for client authentication.
Registration requirements (metadata).
Resources
This section lists documents that we should look into and extend/specialize during the work:
RFC6749 - The OAuth 2.0 Authorization Framework - https://www.rfc-editor.org/rfc/rfc6749.
OAuth 2.1 draft - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12.
RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens - https://www.rfc-editor.org/rfc/rfc9068.html.
RFC7519 - JSON Web Token (JWT) - https://www.rfc-editor.org/info/rfc7519.
RFC8725 - JSON Web Token Best Current Practices - https://www.rfc-editor.org/info/rfc8725.
RFC7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants - https://www.rfc-editor.org/rfc/rfc7523.
RFC 8693 - OAuth 2.0 Token Exchange - https://www.rfc-editor.org/rfc/rfc8693.html.
RFC 8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens - https://www.rfc-editor.org/rfc/rfc8705.
RFC8707 - Resource Indicators for OAuth 2.0 - https://www.rfc-editor.org/info/rfc8707.
RFC7643 - System for Cross-domain Identity Management: Core Schema- https://www.rfc-editor.org/info/rfc7643. Section 4.1.2.
RFC7644 - System for Cross-domain Identity Management: Protocol - https://www.rfc-editor.org/info/rfc7644.
Interesting links
https://connect2id.com/products/server/docs/guides/oauth-client-authentication
https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow
https://oauth.net/articles/authentication/
The text was updated successfully, but these errors were encountered: