I’m making a small web app that allows the user to log in using their Solid credentials on ESS. However, after they log in, there is another separate service that wants to authenticate the user. The way I have this planned is buy serving the session token from the client web app to this separate service, and then having the separate service check if the token is valid with the identity provider from the client’s current session. If it is valid, then they are allowed to use the third-party service and are verified to connect.
Is this the correct way to go about this model? If not, I’m open to recommendations. If it is, how can I craft an https request from the third-party service to the identity provider and receive confirmation that the session token is valid? Thanks.
For more information: the third-party service is also controlled by me, and is potentially being used as a way to find friends by webID, or is at least the long-term goal.
Short answer: no, using the Inrupt SDKs, you can’t. The token is stored in internal memory and not easily accessible from the outside.
You could use the fetch method from solid-client-authn-browser, but this will give you a request with a bearer token that is dpop bound, which means it works for the current request and nothing else.
The authorization header in that request would be a JWT with a short expiry which would have a webid claim in it, you’d need your servuce to verify the JWT and then you’d need to interact with that webid — there’s current no off-the-shelf code for this, but it’s what servers like ESS do when verifying requests.
If this answer sounds like two answers, it really depends on what you’re doing / needing
Thanks for the rapid response. I don’t need to hold the webID claim for a lifetime, I just need a one-time check to see if the session token issued by the user’s identity provider proves they are who they claim to be with their web ID and session token. If it’s valid, they get issued a token to use to interact with the third-party service. The only instance I see needing another check is if that token is compromised by someone else.
My other solution was have something similar to the current model of verifying by sending a code to a certain pod URI, though that has some flaws related to security in my mind.
As far as the JWT claim, that is the one issued in step 13 of the Solid OIDC primer correct?