Authenticating Users

[elf-pavlik]

While #25 focuses on authenticating Clients, here we can focus on authenticating Users. Preferably we can start following up with PRs for specific findings. In #2 we have some relevant points as well, I think we can extract ones related to user authentication here and close #2 which served as meeting notes.

• Authenticating User with Resource Servers vs. Authenticating User with OIDC Provider - I think we have general consensus that while OP can provide freely wast diversity of authentication mechanisms (user can independently choose one's own OP), for authenticating with RS we should have limited, possibly just one, method (user may need to use any number of group storage instances)

I can prepare PR for next Monday formulating above as group finding.

Authenticating with OIDC Provider

• Biometrics authentication (from #2)
• WebAuthn (from #2)
• WebID-TLS (from #2)
• Multi User Device auth (with alternative sensors ie no keyboard or mouse) (from #2)
• When using Clients which need to use Device Code Grant or Client Credentials

Authenticating with Resource Servers

• WebSocket authentication (and authorization)
• Opaque authentication (accept claims without telling a resource server who you are)

Authenticating with Client

• User display information - WebID Profile
• Multiple users using same client in the same operating system session (eg. iOS)

Authenticating with Authorization Servers

• Comes up in approaches where we have Authorization Server other than User's OP

[jaxoncreed]

In terms of authenticating clients, the OIDC flow will redirect with both an access_token and an id_token. The ID token should be used to authenticate the user to the client.

[elf-pavlik]

https://openid.net/specs/openid-connect-core-1_0.html#IDToken

aud

REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case sensitive string.

https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation

3. The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience. The aud (audience) Claim MAY contain an array with more than one element. The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client.

When we useid_token to authenticate the User to the Client, it clearly meets requirements above.

Even if we use OIDC to login to some distinct Authorization Server, that AS will act as Client / RP and will not have another client / app involved in the flow. Trying to make Resource Server to act as Client / RP and have another Client involved in the flow doesn't seem to me like using OIDC as intended.

[elf-pavlik]

Following up discussion on today's Authorization Panel call. I would like to propose that User never directly authenticates with any Resource Server. Since User will always use some client to access resources on various Resource Servers, the User authorizes the client (delegates subset of one's own access to it) in most cases restricting it to some 'kinds' (eg. shapes) of data. Most clients have some special purpose and they only can handle some 'kinds' of data anyways. Resource Servers only verifies that authorization granted to the Client by the User, and based on that know on behalf of which User that Client acts.

[zenomt]

I would like to propose that User never directly authenticates with any Resource Server. Since User will always use some client to access resources on various Resource Servers ...

i think it'll be common for users to log directly in to a site/RS (the "first party" login case), where the site itself is the client of the OpenID Provider. as far as the OP is concerned, this case is and ought to be indistinguishable from the user logging in to any other app.

[elf-pavlik]

Do you mean cases where Client running fully in web browser stays hosted on a Resource Server so they share the same origin? Other than that I don't think we've ever consider Solid Resource Server itself to act as Solid Client. Solid Resource Server acts in few situations as HTTP Client but only accessing public resources so it doesn't require any authorization from any user.

[zenomt]

i mean the user using her web browser to directly access resources on the RS. here the RS is an OpenID Connect client (not an HTTP client). this is what happens today if you navigate to a site running NSS and attempt to access a restricted resource (it'll prompt you to log in with your webid, set a cookie, and then present an HTML viewer for the resource when your browser asks with Accept: text/html).

[elf-pavlik]

I think this only happens because NSS also acts as OP which establishes cookie based session. Many NSS deployments also host data browser (i think mashlib.js) acting as a solid client which fully runs in web browser and uses solid-auth-client module. User can log in to that mashilb.js app/client hosted on NSS RS but I don't think that RS itself acts as OIDC Client. @jaxoncreed does the mashlib.js hosted on NSS but running in web browser act as OIDC Client (it requests id_token from User's OP) or the server side nodejs NSS process act as OIDC Client directly and requests id_token from User's OP directly from NSS node.js process running on the server?