Authorizing clients (apps)

[elf-pavlik]

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
  • OpenID Provider [Solid-OIDC]
  • Authorization Agent [SAI]
• PerformChart's security domain - Client
  • Client [Solid-OIDC]
• ACME's security domain - Resource Owner
  • Resource Server (Storage) [Solid Protocol]
  • Authorization Server [Solid-OIDC]

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:

• 2020-05-04 Authentication Panel
• 2020-05-18 Authentication Panel
• Compelling Use Cases for User-Focused Client Constraining Access Control authorization-panel#67
• Access Control should be the responsibility of BOTH the Resource Server and the Identity Provider, depending on the situation authorization-panel#43
• Why should I trust an app? authorization-panel#46
• Document current acl:trustedApp system web-access-control-spec#56
• Address Issuer restrection in data grants, plus RO Client constraints data-interoperability-panel#223
• Limitations: Limiting access to trusted applications authorization-panel#177