Repository navigation
Can not get OIDC token from NSS via @inrupt/generate-oidc-token #1580
Description
Note: this is about getting an OIDC token from NSS as an IDP, not about getting a token after logging in with username/password.
I tried running @inrupt/generate-oidc-token against both solidcommunity.net and solidcommunity.net:8443 with the same results : I was able to get a link for the browser login page, log in manually, but then got the below on the console instead of the JSON for the token. @NSeydoux - not sure if this is a bug in @inrupt/generate-oidc-token or in NSS. Note, that it tells me that login was successful.
Login successful.
(node:964489) DraftWarning: The DPoP APIs implements an IETF draft. Breaking draft implementations are included as minor versions of the openid-client library, therefore, the ~ semver operator should be used and close attention be payed to library changelog as well as the drafts themselves.
(Use `node --trace-warnings ...` to show where the warning was created)
(node:964489) UnhandledPromiseRejectionWarning: OPError: invalid_grant (Mismatching redirect uri)
at processResponse (/home/jeff/Dropbox/Web/solid/solid-node-client/node_modules/openid-client/lib/helpers/process_response.js:45:13)
at Client.grant (/home/jeff/Dropbox/Web/solid/solid-node-client/node_modules/openid-client/lib/client.js:1237:26)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
at async Client.callback (/home/jeff/Dropbox/Web/solid/solid-node-client/node_modules/openid-client/lib/client.js:460:24)
at async AuthCodeRedirectHandler.handle (/home/jeff/Dropbox/Web/solid/solid-node-client/node_modules/@inrupt/solid-client-authn-node/dist/login/oidc/redirectHandler/AuthCodeRedirectHandler.js:77:24)
at async ClientAuthentication.handleIncomingRedirect (/home/jeff/Dropbox/Web/solid/solid-node-client/node_modules/@inrupt/solid-client-authn-node/dist/ClientAuthentication.js:70:34)
at async Session.handleIncomingRedirect (/home/jeff/Dropbox/Web/solid/solid-node-client/node_modules/@inrupt/solid-client-authn-node/dist/Session.js:45:35)
at async /home/jeff/Dropbox/Web/solid/solid-node-client/node_modules/@inrupt/generate-oidc-token/dist/index.js:82:9
(node:964489) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:964489) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Activity
NSeydoux commentedon Mar 8, 2021
The fact that it displays that the login is successful, when it visibly isn't, looks like an
@inrupt/generate-oidc-tokenissue. However, I'm not sure where the "main" issue is coming from. As far as I can tell, the OIDC provider should check that the redirect URI provided at the authorization endpoint matches the one provided during Dynamic Client Registration. In the case of@inrupt/generate-oidc-token, which wraps@inrupt/solid-client-authn-browser, these URIs both come from thelogincall parameter, so they should match. I tried reproducing the bug this morning, and here is the output I got:Using this token if currently still unsuccessful due to nodeSolidServer/oidc-op#32, but I don't get the same issue as you. Could you detail the steps to reproduce ?
jeff-zucker commentedon Mar 8, 2021
Here's what I did and what I got ... details of my setup below that
Here is my setup : Linux Mint 20.04, node v14.15.1, npm 6.14.8
NSeydoux commentedon Mar 10, 2021
I'm not sure how the bug got initially introduced, but I think I figured out a fix @jeff-zucker. I think we can close this issue and follow up in either inrupt/solid-client-authn-js#1159 or https://github.com/inrupt/generate-oidc-token/issues, and close this issue, because the problem isn't related to the server :).
Thanks for reporting this !
jeff-zucker commentedon Mar 11, 2021
@NSeydoux fixed this on the client end, getting an OIDC token issued and logging in with it rather than username/password now works with ISCAN and Solid-Node-Client using ISCAN against the test server (8443)
jeff-zucker commentedon Mar 12, 2021
Tested from solid-node-client using a generated OIDC token on 5.6.6. - works great now.
bourgeoa commentedon Mar 13, 2021
@jeff-zucker
Could you give me an example how to acquire and use the refresh token ?
and for what kind of process it is needed ?
I think I do not have enough background on the authentification process.
jeff-zucker commentedon Mar 13, 2021
@bourgeoa - the basic idea is that logging in to a server from the command line with a username and password is insecure because the password travels unencrypted. With a token, you never send the actual password, only the token. You can acquire the token either using @inrupt/generate-oidc-token or solid-node-client which calls it behind the scenes. Make sure to have latest solid-node-client, solid-client-authn-node, and generate-oidc-token. The instructions are in the solid-node-client README. Basically it is a script that you run from the console that gives a URL which you open in a browser, login to the IDP, and then the token is sent back to the console. You can then copy and paste the JSON for the token either into a storage vault or directly as the login parameter of a call to login. After that everything is the same as if you had logged in from the command line with username/password. The token lasts about three days, though there are plans to make it last longer. Of course, @NSeydoux can give a better explanation since he actually understands the process. :-)
jeff-zucker commentedon Mar 13, 2021
With ESS (and I believe CSS and Trinpod as well), the OIDC-token is the only way to login outside a browser - there is no username/password flow outside the browser. It would be worth considering if NSS should eventually deprecate using username/password outside the browser.