- Is there support for device logins? Workflow: the user runs a CLI, it generates a link that the user opens in the browser. If the user is logged in, the login finishes in the CLI automatically. If not, they can log in/signup first

Hey!

yes? 🙂

We don't have a dedicated recipe for CLI login, but you can use our passwordless recipe to get this to work. The flow would be as follows: - Create an API that the CLI can call. In this API, you want to call a function from our backend SDK to generate a magic link and send it to the CLI. - The link contains a one time use token and another ID called

preAuthSessionId

. You want to save the

preAuthSessionId

on the CLI and query an API that checks if the

preAuthSessionId

has been consumed or not. - When the user clicks on the displayed magic link, it would open the browser. - Then, on that page, you would check if a session already exists (using our frontend SDK). If it does, you want to call an API giving it the one time use token + the

preAuthSessionId

. In the API, you can do session verification to get the userID and consume the one time use token (using our backend SDK). If the one time use token was consumed successfully, you want to map the

preAuthSessionId

to the userID in your own db. - If the user is not logged in, you can store the one time use token +

preAuthSessionId

in localstorage and ask them to login. Post login, you would do as per the previous step. - Finally, the API that the CLI is calling would eventually see that there is a userID mapped to the

preAuthSessionId

, which it could return to the CLI. One catch here is that to generate the magic link in the first place, you would need to provide an email to the backend SDK function. You can give it a random / unique email and then delete this user once the magic link code is consumed.

Thanks for the suggestion! I've been looking into magiclink and also couldn't figure out a way without using our own db

well, technically, you can do it with SuperTokens without using your own DB. So in the above description, the only place to use your own DB would be to store a mapping of the

preAuthSessionId

to the userID. You could store that mapping with supertokens itself using the user metadata recipe which allows you to map any ID with any JSON. So you could store

preAuthSessionId => {"userID": "..."}

mapping with supertokens and later get that value.

hmm interesting

Cheers. Please feel free to ask more questions. This seems like an interesting case.. i might build a demo app for it as well 🙂

that would be helpful 🙂

cool! Let me try to hack something tomorrow / day after.

Thanks a lot! I'll take a look

happy to help 🙂

Hello, I have the same use case. I've tried this demo but I'm not sure how to use the final JWT to authenticate. I've tried sending header authorization: Bearer {jwt}. but it doesn't seem to work

the final JWT can be authenticated if you use a jwt lib for its verification instead of the verifySession or getSession function that we have.