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

Clarification on authentication vs authorization #158

Open
kjetilk opened this issue Apr 21, 2022 · 5 comments
Open

Clarification on authentication vs authorization #158

kjetilk opened this issue Apr 21, 2022 · 5 comments
Assignees

Comments

@kjetilk
Copy link
Member

kjetilk commented Apr 21, 2022

As previously mentioned, I found the use of the terms "authorization" and "authentication" in the primer especially, but also in the spec, to be confusing.

@justinwb tried to explain to me the Editors meeting that the use of authorization comes from OAuth, where the idea is that the user authorizes an agent to act on their behalf, and that's fine.

However, Solid has maintained a clean separation between authentication as in "figure out who this user is", and authorization as in "figure out if they are allowed to access this resource". It is important to ensure that this architectural property isn't compromised. For what I've read, it doesn't seem that it has been, but the wording may lead people into thinking that the distinction isn't important, or just confuse them.

Therefore, I believe this should be clearly explained, at least the primer, but perhaps in an introductory note in the spec.

As publishing it on solidproject.org/TR will attract a new readership, I believe this is something that should be done before we publish it there. As we discussed this briefly in the Editors meeting, it seemed to be some agreement around that.

@acoburn
Copy link
Member

acoburn commented Apr 21, 2022

This is very simple: Solid-OIDC is concerned only with Authentication. It does this by defining an ID Token: a token that identifies who an agent is. (Note that this is not an access token).

Authorization is what happens afterwards: a user exchanges the ID Token for an access token and then sends that access token to request a Solid resource.

Solid-OIDC does not mandate a particular mechanism for exchanging ID tokens for access tokens: that is beyond the scope of Authentication. UMA is one option, OAuth Token exchange is another. That determination is driven by the Solid Pod and the WWW-Authenticate header it produces. All Solid-OIDC requires is that there be some sort of authorization server. All of this is standard OAuth interaction / architecture; we are not inventing anything new here.

@kjetilk
Copy link
Member Author

kjetilk commented Apr 21, 2022

Right, so that is the explanation that should be provided in the document(s).

The primer currently only mentions authentication in passing before it jumps into authorization flows without further explanation. That does not add to an understanding for a typical audience of a primer, I'd say.

However, it also brings up another question: In a classical Solid server (i.e. NSS), the authorization is provided by the resource server, that's a single entity.

Does Solid-OIDC require that these are split in a RS and an AS, where the access token obtained from the AS is how the access modes are communicated to the RS?

@acoburn
Copy link
Member

acoburn commented Apr 21, 2022

The scope of Solid-OIDC is Authentication. It defines how an ID Token is formatted for use with Solid. Solid-OIDC very purposefully says nothing about access tokens. Any access token produced by an OpenID Connect Provider (per OpenID Connect) is only valid at the OpenID Connect userinfo endpoint. Defining a different access token (i.e. a global access token for use with Solid Pods) is not OpenID Connect, and so that is out of scope for Solid-OIDC.

A resource server (RS) can coexist with an authorization server (AS): that is an impl decision. This specification does not prescribe or constrain the architectural decisions of an impl w.r.t separating or combining the RS and AS.

@elf-pavlik
Copy link
Member

Does Solid-OIDC require that these are split in a RS and an AS, where the access token obtained from the AS is how the access modes are communicated to the RS?

We have been discussing distinguishing responsibilities of AS and RS a lot lately during AuthZ panel meetings on Wednesdays. While some implementations will very likely have the two tightly coupled, other implementations should be able to keep them as separate services. It is possible that the AS - RS communication might stay implementations specific for now. Solid-OIDC doesn't make any assumption about how AS and RS use access tokens and (if at all) token introspection. It also doesn't assume any specific Authorization system, AS - RS can use WAC, ACP, anything they can agree on.

Either way, other parties need to discover AS via the as_uri parameter in the WWW-Authenticate header of the response from RS.

If we want to reuse OAuth, the access token should be issued by the Authorization Server associated with the Resource Server. The Resource Server itself shouldn't issue any tokens, it also shouldn't accept access tokens from any other Authorization Server than the one associated with the RS.

I believe solid/authorization-panel#290 provides a nice example where AS associated with RS shows more of its potential.

@kjetilk
Copy link
Member Author

kjetilk commented Apr 25, 2022

@acoburn What I'm trying to say here is "Don't whisper to the prompter, speak to the audience!" :-)

If "The scope of Solid-OIDC is Authentication.", then that should be the first thing you say in the abstract, and as important things bear repeating, say it again in the introduction. This is a spec, not a crime novel, spill the beans, kill the suspense, don't let the audience figure it out for themselves.

How access tokens are out of scope, should literally be spelled out in "out of scope", you have the section already, why isn't it there?

So, lets say that I was writing an implementation of a resource server and I was looking for how authentication works in Solid. I start from the top of these documents. I get to the sentence:

This specification is written for Authorization and Resource Server owners intending to implement Solid-OIDC.

so, I'm likely to go "ah, resource server, ah, that's me, but wait, Authorization Server...? I was looking for authentication, have I come to the right place?" The abstract is not sufficient to set the stage, it needs to frame it in more clarity also in the introduction.

I personally think the documents would be well served by a reorganization centered around the audience: "If I'm writing a Resource Server, what do I need to know?", "If I'm writing an Authz Server, what do I need to know". Or perhaps that's more of a primer thing.

As an anecdote to illustrate the concern here, the "Solid-OIDC" document has 9 occurrences of the string "authen" and 30 of the string "authoriz". The primer has 13 vs 42. When you have that kind of slant, it puts great demands on the introductory texts to frame the scope of the normative statements.

@elf-pavlik Yes, that's good. My concern in that area is mostly about how the protocol reduces in the simpler cases. That will also include a concern about public access (where the RS shouldn't need to ask the AS) and just "authenticated agent", where the AS should be able to provide an access token with little ceremony.

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

No branches or pull requests

3 participants