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!