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

Expose the current issuer #2153

Open
2 of 4 tasks
mrkvon opened this issue May 20, 2022 · 10 comments
Open
2 of 4 tasks

Expose the current issuer #2153

mrkvon opened this issue May 20, 2022 · 10 comments

Comments

@mrkvon
Copy link

mrkvon commented May 20, 2022

Search terms you've used

issuer

Impacted environment

In which environment would the proposed feature apply ?

  • The browser
  • Node.js
  • Other (please specify): ...
  • I'm not sure.

Feature suggestion

[...] "retrieve the current issuer from the session" [and] expose that via the ISessionInfo interface, potentially

In certain cases, it may be useful for an App to know the OIDC issuer which was used to authenticate current user.

E.g. a user with webId https://someuser.solidcommunity.net/profile/card#me may have an issuer https://solidcommunity.net, and we want to know that.

Expected functionality/enhancement

Currently, ISessionInfo doesn't expose issuer, and it could.
The issuer is exposed within the Authorization header of the fetch function as iss property of a JWT token. It's also exposed in localStorage, however i'm told this is going to change.

Actual functionality/enhancement

Expose the current issuer in ISessionInfo (or in other standard way)

Use Cases

  • As of now, some OIDC Identity Providers (typically https://solidcommunity.net and other NSS-based servers) don't include solid:oidcIssuer in personal profile documents. This is sufficient for authenticating into NSS Pods, but fails when authenticating using e.g. @solid/access-token-verifier.
    So, sometimes an app needs to fix such incomplete profile document (if it can), to make it compliant. Hence, it needs to know the issuer.

  • Also, perhaps an app wants to show the current issuer in UI... 🤷🏾‍♀️


ping @jeff-zucker

@jeff-zucker
Copy link

jeff-zucker commented May 20, 2022

On a server compliant with the OIDC spec, it is impossible to login using OIDC unless there is a solid:oidcIssuer predicate in the profile. So it is impossible for an app to login with OIDC and grab the issuer from the login unless there is already an issuer in the profile. The only reason this works on NSS is that it is both IdP and Resource provider and auto-assigns itself as the issuer. NSS has already been patched to include the oidcIssuer triple in all new profiles. If you want to fix a missing NSS issuer on older profiles, the issuer will always be NSS.

@ThisIsMissEm
Copy link
Contributor

@jeff-zucker true, you could look at the profile, but if the profile includes multiple solid:oidcIssuer predicates, then you'd need some way to figure out which was used to authenticate the current session. We do already keep track of this internally, it's just not exposed as a public API: https://github.com/inrupt/solid-client-authn-js/blob/main/packages/core/src/sessionInfo/ISessionInfo.ts#L71

@jeff-zucker
Copy link

jeff-zucker commented May 31, 2022

The spec (which should be ready for public review real soon now) currently says about apps wanting to login -

  • 0 issuers : inform user their profile is broken
  • 1 issuer : redirect there for login
  • more than 1 issuer : offer the user a choice of where to login

Some sort of "preferredIssuer" predicate would be useful in this situation.

@ThisIsMissEm
Copy link
Contributor

Yeah, but once you are logged in, being able to find out which issuer logged you in could be useful; we already keep track of it, it'd just be a matter of exposing it as a public value.

@jeff-zucker
Copy link

Ah, I see, yes an app might want to know that.

@mrkvon
Copy link
Author

mrkvon commented Jun 1, 2022

If you want to fix a missing NSS issuer on older profiles, the issuer will always be NSS

Is there an easy way how to get issuer from webId? It seems trivial for [protocol]://[username].[host]/profile/card#me, like solidcommunity.net, but in general, i don't know how to do this.

Trailing slash is also an issue. (To have or not to have?)

Anyways, good to hear that spec is getting more consistent here. 👍🏾 Hopefully the reality will follow and this will become a non-issue soon.

@jeff-zucker
Copy link

NO, don't do that. There is no guarantee that the WebID even points to the issuer. It doesn't on ESS. But other than older profiles on NSS, the oidcIssuer should be listed in the profile so therefore the only time you'd need to munge the WebID to find the issuer is on NSS so it works in that one case as you described. '

An issuer does not have the trailing slash - that would make it the URL of a container. It is the origin i.e. the protocol + the host + the port.

@mrkvon
Copy link
Author

mrkvon commented Jun 1, 2022

NO, don't do that.

So, do you suggest to only fix well-known NSS profiles? Or perhaps to give up on all older NSS profiles? The former sounds like a sensible compromise. The latter would be rather unsatisfying...

An issuer does not have the trailing slash

I've seen trailing slashes on solidweb.me (CSS). E.g. see https://solidweb.me/test/profile/card

@jeff-zucker
Copy link

You can't fix the issuer on anything other than NSS because if the issuer isn't in the profile, you can't login to fix it. On NSS you can fix the issuer because it provides itself if none is in the profile. So, yes, I suggest that on NSS you use the WebID to find find the issuer (which works on NSS but not necessarily elsewhere) and fix the profile.

@jeff-zucker
Copy link

I've seen trailing slashes on solidweb.me (CSS). E.g. see https://solidweb.me/test/profile/card

The OIDC spec shows the oidcIssuer with no slash but does not specifically say that it should be omitted. @acoburn - is solidweb.me wrong to include the trailing slash on the oidcIssuer triple?

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

No branches or pull requests

3 participants