Skip to content
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

OAuth2 specifikationer och profiler #27

Open
martin-lindstrom opened this issue Jan 16, 2025 · 0 comments
Open

OAuth2 specifikationer och profiler #27

martin-lindstrom opened this issue Jan 16, 2025 · 0 comments
Assignees
Labels
discussion A discussion

Comments

@martin-lindstrom
Copy link
Collaborator

martin-lindstrom commented Jan 16, 2025

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:

Interesting links

@martin-lindstrom martin-lindstrom self-assigned this Jan 16, 2025
@martin-lindstrom martin-lindstrom added the discussion A discussion label Jan 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion A discussion
Projects
None yet
Development

No branches or pull requests

1 participant