Make the login process user friendly

[anushkavidanage]

Since the authentication is done via OIDC, when a user logged into any of our flutter apps they have to go through a lengthy process of multiple steps.

1. First a user has to click the login button of the app.
2. Then user will be redirected to a login page of the POD server and user have to provide username and password.
3. Then user has to confirm the app id in another browser window.
4. After all of this the user will get redirected to the app again.

This process is confusing and making the whole experience very complicated.

This issue is to research and see if we can somehow do the whole login process within a the app window.

[anushkavidanage]

Summary of the investigated issue.

OAuth 2.0

OAuth 2.0 is an authorisation framework for granting access to resources. It defines four roles; - the resource owner (the user) - the client (an application acting on their behalf) - the authorization server (AS) - the resource server (RS) and a set of grant flows for getting a token from the AS to the client without the client ever seeing the user's credentials. The dominant flow for interactive applications is the authorization code grant with PKCE: the client redirects the user's browser to the AS's authorization endpoint with a client_id, a redirect_uri, a requested scope, and a hash of a random code verifier; the user authenticates and consents at the AS; the AS redirects back with a short-lived authorization code; and the client then POSTs that code plus the original verifier to the token endpoint, receiving an access token and optionally a refresh token. The access token is a credential the client presents to the resource server. However, nothing in base OAuth tells the client who the user actually is; conflating the possession of an access token with a proof of identity is the general issue with OAuth.

OIDC

OpenID Connect (OIDC) fixes the above issue by layering a thin identity protocol on top of OAuth's authorization code flow. A client requests the openid scope, and in addition to the access token the OpenID Provider (OP) returns an ID token: a signed JWT whose claims assert the authentication event. The client validates the signature against the OP's JWKS, discovered through the /.well-known/openid-configuration document, and can fetch additional profile claims from the UserInfo endpoint. The trust model here is deliberately closed-world and bilateral: the relying party (client) has registered with the OP in advance, the OP knows which client it is issuing for, and the resulting identity is scoped to that one provider–client pair. A second client does not get the same token.

Solid-OIDC

[Solid OIDC](https://solidproject.org/TR/oidc-primer)

Solid-OIDC keeps the authorization code + PKCE process but re-engineer the trust model for an open world in which any client may talk to any POD hosted by any Solid server, with no prior relationship between them. There are three main changes to Solid-OIDC.

1. User identity is a WebID rather than a provider-local subject identifier: the spec adds a webid scope that OPs advertise in their discovery metadata, and the resulting token carries a webid claim holding the user's WebID URI. Because a resource server has no pre-existing trust in the issuer (Solid server), it accesses the WebID profile document and checks that the document itself names that issuer (via solid:oidcIssuer), so the assertion is only accepted if the identity and the provider vouch for each other.

2. Dynamic or manual client registration is replaced (or supplemented) by Client Identifier Documents. The client_id is itself a URI pointing at a JSON-LD document describing the app and its redirect URIs, so a client can be recognised by any OP without registering anywhere first.

3. Tokens are proof-of-possession rather than bearer (user's) credentials. The client generates a keypair, sends a DPoP proof JWT signed with the private key on every request, and the token is bound to the JWK thumbprint of that key, so an leaked token is useless on its own. Authorisation happens separately at the Pod, where ACL or ACP rules are evaluated against the WebID the token asserts.

Can we have an in-app login?

An in-app login or embedding the Identity Provider's (in our case Solid server) login form in an in-app WebView (rendering username/password inside your own screen) is exactly what OAuth security practice (RFC 8252 - https://www.rfc-editor.org/info/rfc8252/) says native apps shouldn't do. Having such mechanism breaks the security the protocol provides by revealing the user's credentials to the third party client.

This is especially important with Solid-OIDC where a client app is not registered with a OP beforehand. The client's identity is simply a JSONld document. Therefore, the client can't be trusted with credentials, breaks SSO. This is the reason package:oidc uses AppAuth's ASWebAuthenticationSession/Custom Tabs on mobile instead, which already overlay as an in-app sheet rather than switching to a separate browser app. For desktop however, it genuinely opens the system browser, since there's no AppAuth equivalent there, and in web a popup/new tab is opened for auth.