Support `#getIssuer` which uses hints in application URL

[jeswr]

There are some use-cases where you get sent to an application from an IDP provider. For example, when your Pod provider has a set of recommendations to launch into. In this instance it may be useful to hint the users WebID or IDP provider so that when they log into that application they are sent straight to their IDP provider rather than needing to suggest this.

Concretely, we would implement a #getIssuer method which inspects the current URL an application is at to see if there is #autologin/:webID appended to a URL and if so use the IDP of the WebID to log in.

For reference see the issue that @ylebre raised on NoelDeMartin/media-kraken#54

@ylebre I do wonder if this is the right approach -- could you not bypass all of the redirects by just completing the OIDC flow, i.e. direct straight to the applications log-in URL with an authorisation code.

[ylebre]

Hm, interesting idea - I think that would only work if we have all the client registration information already available, which I think would not always be the case?

I think since every Solid application will already have a login flow, it would make more sense to just trigger the existing flow and let the application do whatever it would normally do after that. This approach also leaves the Solid application developer free to rework the whole login flow if they need to.

I see that the current implementation takes the IDP instead of the WebID. While I think passing the webID better conveys the users intent, I do also have the IDP available. If it makes the required change smaller, I could pass that instead. The application can just act as if the user entered the IDP in the login field and take it from there.

[langsamu]

Here's how I see how this library needs to work.
In the following sequence of events (ordered from latest to earliest), each step strictly depends on the one preceding it:

• Send upgraded request
• Upgrade request with token
• Exchange code for token
• Extract code from authorization response
• Receive user when they're redirected back
• Redirect user to authorization endpoint URI
• Extract authorization endpoint URI from metadata document
• Get metadata document from well-known address based on authorization server URI
• Obtain authorization server URI

A WebID is intentionally not mentioned here, though it is a way of obtaining the AS URI. Another is to ask the user directly. Yet another is some heuristic based on storage URI. Some apps will even hardcode it, which is also fine.

To enable all of these cases, I will keep dependencies to minimum, which means, in this case, that Authorization Code Flow functionality will not depend on WebID.

I will, however, add other functionality that makes it easy to get an AS URI from a WebID (solid:oidcIssuer). I will also add UI functionality for asking the user for an AS URI and for a WebID URI.