how are redirect_urls authenticated?

[bblfish]

As I understand identifying Apps indirectly via the Origin header is now no no longer correct, and one should use the redirect_url of OAuth as an identifier for the app. It is clear that Origins are much too broad to identify a single application.

I am not sure though how the OAuth Authorization server authenticates the app? How does the OAuth server distinguish one app from an origin from another?

[zenomt]

there are two main issues with the Origin header. the most important one is that, when authenticating with a bearer token (under control of Javascript and able to be sent to other agents), the Origin header can't be trusted by the Resource Server or the user because it might not be coming from the user's trusted web browser (and therefore might be set to anything). the other issue is that the user might wish finer granularity than Origin to identify apps she's using, particularly when she trusts the origin enough to host independent apps (say, because she controls the origin, or it's https://solid.github.io or something).

the authenticity of the redirect_uri is established to the user via her trust in her web browser and her OpenID Connect Provider. the OP sends the id_token and/or access token and/or authorization code to the app by redirecting to the redirect_uri with this information encoded in the URI query or fragment identifier. the user trusts her OP to do this redirect, and she trusts her browser to follow this redirect and handle it correctly. a generally trustworthy OP is supposed to take steps to ensure its login and consent screens (if any) are running in a no-frames non-inspectable-by-the-app not-drivable-by-the-app frame-busted clickjack-safe trusted browser context, and the user is supposed to take care that she never gives her login credentials or consent except to her OP showing in such a safe context.

the Resource Server ultimately has to believe the user about the redirect_uri, because it's not independently authenticated by the RS (only by the user).

note that the user herself can cause an OP to claim a different redirect_uri by using a modified user agent or something like curl. the OP has no way to know that a redirect_uri is actually followed. note too that the user can run her own OP and make it claim anything.

[bblfish]

Thanks for the details.

So for web sites that ask you to login via say Twitter or Github, such as the solid forum page the redirect_url is going to be a url back to the site you want to login to.

What is the redirect_url for Single Page Apps? Is it the URL of the html at which the JS is located on the web?

[jaxoncreed]

We use the origin of the redirect_url so it would be the same with a single page app as a multi-page app.

To clarify, the origin header is used to identify an app, but not to authenticate it. The redirect_url embedded in the token is used to do that. See aud here (https://github.com/solid/webid-oidc-spec/blob/master/application-user-workflow.md#14-generates-an-id_token)

[bblfish]

I think the proposal in User controlled Authorization App would enable the Authorization App loaded from a secure Origin and holding the private keys for all applications launched, to know the exact url of each launched app, since those were the urls used to launch the apps. This makes it possible to now both identify the App type (the launch URL) and the App instance, using a private key controlled by the App Launcher. The App Launcher could the even give the App instance (running in a particular browser) a particular WebID (though blank nodes will also do, as keys are inverse functional properties).

So the App Launcher could write to the users personal Pod the following triples for each app:

</app/calendar#FirefoxOnLinux> a :App;
   :appLaunch <https://office.app/2019/Calendar.html>;
   :browser "...";
   cert:key [ ... ] . 

[elf-pavlik]

I think we can close this issue and follow up in other related issues

• Authenticating Clients Authenticating Clients #25
• Identifiers for Applications Identifiers for applications authorization-panel#30

In both of them we need to address what role redirect_url plays and they give clear context of authenticating and authorizing clients.

Otherwise we should define some criteria for resolving this issue, preferably by PR.

[jaxoncreed]

Agreed. We'll continue the conversation in those