Does a token last forever ? How to use the app id and secret?

Hi,

i have understood the API and I can make REST calls with curl. The “copy curl” in https://speckle.xyz/graphql was very handy !!!

Now I want to make my own application that should be able to make queries in the database through the url.

Does the token last forever? Is it transferred with POST? Is it encoded? Usually the tokens last only one time.

curl ‘https://speckle.xyz/graphql’ -H ‘Accept-Encoding: gzip, deflate, br’ -H ‘Content-Type: application/json’ -H ‘Accept: application/json’ -H ‘Connection: keep-alive’ -H ‘DNT: 1’ -H ‘Origin: https://speckle.xyz’ -H ‘Authorization: Bearer [mytoken]’ --data-binary ‘{“query”:“query{ user {name, streams {totalCount, items {id, name, commits {cursor, totalCount, items {id,message,totalChildrenCount, referencedObject}}}}}}”}’ --compressed

where [mytoken] is the actual token. I assume that token is not for prolonged use, therefore, I was checking the app id and secret.

Should I create my own code challenge from App secret as verifier?:

code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

Cool, I like to see you’re getting along with speckle more and more! All valid questions - we’re really running behind on docs, so apologies for that.

Tokens in general

They’re treated as passwords server side. They only exist in clear text - server side - once, when they’re generated. Afterwards, they’re salted and hashed before being stored.

Personal access tokens

Personal access tokens are valid for a longer period of time - they theoretically never expire. They behave just like github ones!

I’m talking about these:

Applications, auth and tokens

This is a longer story. Do check how the graphql explorer that’s built into the server actually handles the auth flow - it’s actually a separate app!

In short, and from memory, the authentication flow works like this, once you register an app:

From your app, redirect a user to “allow access” to their speckle account to the following url: https://serverUrl/authn/verify/${appId}/${challenge}:

Re challenge: yes, it should be a random string! Feel free to generate it as you see fit. They will be prompted with the following dialog:

If the user selects “allow”, they will be redirected back to the redirect url you specified during the app registration step with an access code.

You can then exchange this access code for a token and a refresh token from the server, together with the correct challenge & secret.

A note on secrets and public apps In the case of apps that cannot reliably hold a secret, also called public apps in oauth terminology - e.g., frontend applications, mobile applications, desktop applications - pretty much anything besides server-side backend apps - secrets are not really secrets. *This is fine - it's the redirect url that matters.*

And that’s it - your app can now make actions on behalf of that user - read or create new streams, create commits, etc. Please note, these actions need to be specified in the app’s requested scopes first.

App tokens expire after a while (can’t remember now), but that’s what the refresh token is for - you can exchange that for a new token (and a new refresh token).

I’ve got a pending task to create a tutorial on this, I’ll try and move it up the priority list!