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

Authorizing clients (apps) #517

Open
elf-pavlik opened this issue Apr 5, 2023 · 0 comments
Open

Authorizing clients (apps) #517

elf-pavlik opened this issue Apr 5, 2023 · 0 comments

Comments

@elf-pavlik
Copy link
Member

elf-pavlik commented Apr 5, 2023

This issue acts as a follow-up to the conversation from the CG meeting on 2023-03-22 around #504

One of the main aspects relates to deciding who and when has the authority for authorizing the client. I will discuss it based on: Use Cases and Requirements for Authorization in Solid: 2.5.2. Limiting application access while not acting as resource controller

sequenceDiagram
  autonumber
  box green Alice
  actor Alice
  participant OP as OpenID Provider
  participant AA as Authorization Agent
  end
  box orange PerformChart
  participant C as Client
  end
  box blue ACME
  participant RS as Resource Server
  participant AS as Authorization Server
  actor ACME
  end
  Note over C: acts on behalf of Alice
  C -->> RS: GET /project-x
  RS -->> C: Project X
Loading
sequenceDiagram
  autonumber
  box purple Bob
  actor Bob
  participant OP as OpenID Provider
  participant AA as Authorization Agent
  end
  box orange PerformChart
  participant C as Client
  end
  box blue ACME
  participant RS as Resource Server
  participant AS as Authorization Server
  actor ACME
  end
  Note over C: acts on behalf of Alice
  C -->> RS: GET /project-x
  RS -->> C: Project X

Loading

We have two actors Alice and ACME, sometimes called SocialAgents [SAI] and one application - PerformChart. Colored boxes mark distinct security domains:

  • Alice's security domain - End user
  • PerformChart's security domain - Client
  • ACME's security domain - Resource Owner

In mentioned use case 2.5.2, ACME (the Resource Owner) grants Alice (the End user) read-write access to selected projects. ACME gives Alice full freedom to access those projects using whatever application they choose. Alice decides to access them using two different applications, one of them - Performchart - only does analysis and visualization so Alice only delegates read-only access, based on read-write access granted to her by ACME.

In SAI we have it specified and implemented using Authorization Agent, where an Application (here PerformChart) redirects Alice to her Authorization Agent where based on the read-write grant from ACME, Alice can create a delegated read-only grant to PerformChart. To be specific Alice can also further narrow down access to which projects she delegates.

During the meeting, @timbl brought up a different use case (which I recall he mentioned already some years ago). If we use a variant of the use case above, ACME would not leave Alice full freedom to choose with which application they will access the projects ACME granted them access to. Instead, ACME will take the authority to specify which applications are allowed.

I agree that in some situations authority for authorizing the client could be claimed by the Resource Owner, while in others left to the End user. When it comes to enforcing Resource Owner restrictions on clients we should keep a few things in mind.

In Solid-OIDC, the OpenID Provider verifies the identity of the client and sets it as azp claim in the issued ID Token. Commonly the End user has the freedom to choose (sometimes fully control) the OpenID Provider. In that case, they always have at least the potential to set the client's identity to whatever they want. This makes enforcement of restrictions set by the Resource Owner unreliable. I think there are a few variants of this scenario:

  • The Resource Owner restricts both the choice of clients and the choice of OIDC Providers, in ACP this could be expressed using acp:client and acp:issuer matchers.
  • The Resource Owner trusts that the End user will not use control over OIDC Providers they use and only restricts the choice of clients.

In the real world, they will be even more diversity of scenarios, for example, both the Resource Owners and the End user define their trust on a level of some certification authority (or federation), as long as the client is certified (federated) in at least one common authority it can be used.


This topic was already discussed on various occasions in the last few years, here are just some relevant references:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant