Alternative Authentication Flows

[laurensdeb]

Context

This PR sets up a Markdown file detailing some use cases for authentication flows that do not fit in the OIDC Authorization Code Grant flow we currently depend upon within the Solid-OIDC specification. It also proposes three potential solutions we have already envisioned like using OAuth 2.0 Token Exchange with the OIDC IdP, expanding the UMA Authorization Service's supported profiles or introducing these specific flows into the specification.

It is mainly intended to start a discussion on this topic.

Further information

• Issue Authorization server behaviour for Client-Credentials Grant flow #75
• Discussion in the panel meeting of February 14, 2022.

[elf-pavlik]

I think this document serves as a good starting point. As we dive deeper it will need to transform into mini spec complementary to the main solid-oidc, but we can make it iterative process.

[acoburn]

This is a great starting point (some minor editorial suggestions are included)

Some of the delegation-related flows can be addressed with refresh tokens via normal authorization_code flow (i.e. user logs in and gives the app a refresh token that is used to act on the user's behalf). But that is only valid for cases where (a) the user has initiated the flow via a browser-based operation, (b) the OP supports refresh tokens, and (c) delegation actually makes sense. Even so, this flow would likely not work in constrained environments (at the very least, there will be implementation difficulties).