I’m writing my own Solid authentication implementation in Perl and got it all working. But I don’t seem to be able to request refresh_tokens. I’m using the Solid OIDC Primer as guideline to build an implementation. There is no mention of how refresh_tokens should work. But, from information I found on the web I need to send a POST request to the OP token_endpoint:
POST {OP_TOKEN_ENDPOINT}
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&
refresh_token={THE_REFRESH_TOKEN_FOUND_IN_THE_AUTH_RESPONSE}&
client_id={THE_CLIENT_ID_OF_RP}
But all I get are Internal Server errors at the community server and inrupt server. I’ve tried adding DPoP headers, Authentication headers, any combination of headers with the same responses from the server.
Any insight what is needed is very much appreciated!
Thanks Vincent, indeed I get the same 500 Internal Error respons at the inrupt.net server. It is as mentioned the issue #1533 where refresh_tokens are not yet implemented for Node OIDC.
@inrupt/generate-oidc-token will let you open a browser window to your identity provider, sign-in, and then send a token back to your command-line. It can then be used as proof of authentication anyplace you are authorized. It works with inrupt.com (ESS), and with all up-to-date versions of NSS (e.g. solidcommunity.net). The ESS token expires after 30 minutes so for many cases you might want to login to NSS and authorize your NSS webid to access your ESS data.
Additionally, on NSS servers, you can login outside a browser using username/password and get back a token.
Solid-Node-Client supports both ways of getting a token from nodejs scripts.
There are libraries to get Solid tokens written in Perl, Rust, Python, and Kotlin listed here though I haven’t personally tried any of them.
This is an unfortunate error of the server, but I think it should reject your request anyway (don’t take it personally!)
For Solid, DPoP (draft-ietf-oauth-dpop-03) applies and gives you a more precise description of the access token request. If you want to request an access token, you need to present a DPoP proof to the token endpoint, at least so that the server knows which key it should bind the access token to. If the refresh token was not bound to your key, then the server has no way to know your key. If the refresh token was bound to your key when you got it, the server needs to check that you still own this key. By the Solid primer, the access token must be DPoP-bound, so you must send your key somehow.
I get it that the “Token Instantiation” section SOLID-OIDC of the primer does not require public clients to have a key to make DPoP proofs. I think this is simply an error.
As a heads-up for people reading this in the future, I’ve heard that this expiry time is likely to be lowered even further in the future. Instead, every request you do will also result in a new refresh token being returned in the response, which you can then use for your next request (“refresh token rotation” is the term to enter in your search engine I believe).
(As for updates on the progress, the GitHub issue is probably best to follow, and it looks like there hasn’t really been any, unfortunately.)
Instead, every request you do will also result in a new refresh token being returned in the response
This would be very unfortunate, because most OIDC implementation, just like Apple, don’t want the refresh token stored on the device. This would drive us further away from the currrent web, so there needs to be strong reasons for that.
[disclaimer, I do not work for Inrupt and do not represent them] My understanding is that a) out-of-browser access is (understandably) low priority for Inrupt, that b) we should not expect a longer token from them any time soon c) that when they do fix it, it will be a solution using verifiable credentials, which will provide a complete solution. It’s also my understanding that it already is a rotation token but that step does not solve all the issues.