Hi there. Our team has been using Auth0 with great success for the last 2 years:
Node.js server on Heroku running our Graphql API
Angular SPA, using passwordless email login
This works great with the Auth0 roles and permissions system. Now we are working on a new feature to our customers; make it possible to extract the data from our Graphql API into PowerBI/Qlik/Tableau. For this they need a token somehow, that never expires. On our Node.js server, we can then validate this token, and get the users permissions/roles.
In the Auth0 landscape, how would we implement this - what are the terms?
Thanks for the help - it’s a big platform, so guidance is much appreciated
@konrad.sopala you are my hero here - do you have any ideas for token-flow described above?
Off the cuff this sounds like a use case for refresh tokens. Refresh tokens never expire and allow the holder to return to the authorization server to get new access tokens as needed. The usual model here is:
User A authorizes Service B to act on the user’s behalf for some (possibly limited) set of actions,
The authorization server issues an access token and a refresh token,
When the current access token expires Service B returns to the authorization server with the refresh token, requesting a new access token, so Service B can continue to function on the user’s behalf without User A’s intervention.
Ok, so let’s say I develop a UI in our Angular app, where User A can click a “generate API access” token. He will then copy this token, and use it in a Power BI/Qlik/Tableau app, that will read data from our API every day. Under the hood, the token is actually concatenated access_token and refresh token into something like “access_token|refresh_token”.
Serverside, I can then split on the “|”, and create a fresh access_token (if needed) with the refresh_token.
Is it just me, or does that sound weird?
Every single time Power BI/Qlik/Tableau would load data - the access_token would essentially be expired, and our API server would have to create a new one?
I think what you have there is pretty much correct. Once the user authorizes the service / API to act on their behalf, the service retains the refresh token, at least until the user decides to revoke that access, at which point the refresh token would be invalidated. As long as the refresh token is valid, the service / API can request new access tokens with the authorizations that the user previously approved.
Probably obvious but important to be explicit: Super important to store the refresh token securely. It cannot be stored in a single-page app. If you are building an SPA you should still have a back-end component for securely handling refresh tokens.
I may be leading you down the wrong path here … I am thinking in terms of standard OAuth flows.
If I understand what you are trying to do, you want PowerBI/Qlik/Tableau to access your Graphql API on behalf of the user. I’m not exactly sure how this would work in PowerBI/Qlik/Tableau, but the usual model is: the user authorizes PowerBI/Qlik/Tableau to act (query the API) on the user’s behalf. PowerBI/Qlik/Tableau would use the resulting access token to talk to the API. Once the access token expires, PowerBI/Qlik/Tableau would go back to the authorization server to request a new access token, for which PowerBI/Qlik/Tableau needs the refresh token.
@James.Morrison might have someone else on here who can confirm the approach.
Ok, that is not what I am trying to achieve. Sometimes it’s easier to explain something with an example. What I would like to do, is exactly what Twilio does.
User visits twilio app, and logs in with normal email/password.
Here the user can create a new token, could for example be called “PowerBI-token.” (it can also be deleted from here - if not needed):
The API key from the above step can now be used by a script/powerBI/data-loader/postman. The key does not need to be refreshed or anything, it just works. (Actually very similar to the Auth0 management API key): https://{AccountSid}:{AuthToken}@api.twilio.com
So my question is, how do I create such a key in the Auth0 world?
I would be awesome if the key was associated with the user, but only had read access (for example).
That’s much clearer! This scenario is probably a bit beyond my ken. I don’t think you can implement that type of “API key” using Auth0** but I wouldn’t bet money on that. I think if @nicolas_sabena or @jmangelo have a chance to respond we’ll get a more definitive answer.
**I mean, I can think of one way it might work but it seems messy to me: create one M2M client in your Auth0 tenant for every single user, then use the client secret as the API key.
Thanks for the help so far I actually read something about your idea with M2m client somewhere in the community, but that sounds so weird/wrong and not scalable.
If it turns out not to be possible, then I will have to roll my own API key implementation
Going on memory here but I vaguely recall this coming up before and the answer was something along the lines of “Auth0 doesn’t provide that type of API key / key management service”.
I already strated developing it myself using the jsonwebtoken lib on our Node server. Thanks for the help - I will mark this as resolved because I think you are correct. Auth0 does not support this feature.
Sorry the times are busy and I cannot make it to every topic Can you submit it @alexab providing your context to our product management team as a feature request? They will contact you within 10 business days. Here’s the form:
I actually read something about your idea with M2m client somewhere in the community, but that sounds so weird/wrong and not scalable.
Can you submit it 
