Authenticating Clients

[elf-pavlik]

I would like to clarify how, when and with who clients have to authenticate. OAuth provides couple of mechanisms for Client to Authenticate with Authorization Server. Also for Sender Constrained (bound) tokens, Client proves possession of private key to Resource Serve, which we can also consider as a from of authenticating (possibly relying on different way to identifying the client https://github.com/solid/authorization-and-access-control-panel/issues/30)

During Authorization Code flow we rely on redirect_uri discussed in #22 and we also should document in one place how we rely on it for identifying and authenticating clients.

I think we also need to clarify client authentication when using refresh tokens, especially if we consider issuing client_secret and expecting client to authenticate using client_id & client_secret. For fully in browser applications, non extractable CryptoKey provides more secure way of keeping secret than plain text client_secret and since we use Client Constrained (bound) tokens we require clients generate private key anyways. We could use Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants for clients to also use their private key for authenticating with authorization server, in that case we could possibly rely on Client Credentials Grant and don't even need to use refresh tokens.

[elf-pavlik]

Regarding aspect of Client authenticating to Resource Server. Depending on which identifier RS needs to authenticate we seem to have different reliance on Authorization Server. If client only needs to identify client by the key it holds and to which the token stays bound, RS can directly verify possession of that key. If we rely on some identifier like redirect_uri, RS can't directly verify it and needs to rely on Authorization Server using it in Authorization Code grant.

Requirement on which identity client has to prove to Resource Server also seems related to outcomes of Authentication panel. If access token includes (by value or reference) all the client authorization information that Resource Server should apply to the client using that access token, we can think of those authorization as 'semantic scopes', Resource Server doesn't need to verify any other client identity and use it to discover authorization details it should apply to the client.

[jaxoncreed]

If we rely on some identifier like redirect_uri, RS can't directly verify it and needs to rely on Authorization Server using it in Authorization Code grant.

Unless the RS requires a token that it issues itself. As you mentioned in today's panels, that could be an option in the rare case that the RS wants to identify the client.

[elf-pavlik]

Yes, precisely some AS would still issue the token and RS would need to rely on that AS verifying redirect_url, just it would be AS designated by a user with acl:Control and not one associated with any other user with some other mode of access.