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!
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!