Refresh token are for oAuth2 authorization_code. You are a oAuth provider if you are doing thing this way! You choose this way, there’s nobody that force you to go that way (except your boss ;p). Refresh token are not needed when using oAuth2 client credentials for examples. Same for password oAuth2 (that could be an option too for your case).
And in all case, this mean that the App that is calling your API need to store the access token and refresh token on their side to be able to call your API.
Any solutions you may take, you are free to modify the “standard” oAuth2 protocol. But you will need to handle each step manually.
And the “authentication” service, is not really in Bubble DB. It’s on your API, but you are using user DB to link Bubble account to your API Account. Follow the authorization code oAuth2 process mean that the servie to authenticate your user is really your API, even if Bubble create a user in DB (that is used to store access token, refresh token and expiration)
If you have a page that is only for user to authenticate to API, you can always use the When undhandled error happen and consider the access token failed. And process to get a new one.
You can also “continue” the WF even if the error (by checking that in API call in API Connector) and check if the API have returned something or not. If not, you can consider failed and fetch a new token
And in all case, this mean that the App that is calling your API need to store the access token and refresh token on their side to be able to call your API.
How is it that bubble does not have a way to do this and I have to do everything manually. Again JWT authentication is industry standard. Doing this for every call is not feasible and also with Data Api call is not actually possible.
There’s a way to do that. And this is the user-agen oAuth2!
JWT is a different protocol. And JWT is not dynamical in Bubble. So this mean that you cannot use it directly and need to handle that manually if each user have a different JWT.
In mose case, JWT is used for server to server process and doesn’t involve a user to “authorize” app.
Ok so I will have to take a provider like Auth0 and try to use it as Authentication Server but it is weird that I cannot use my app as Authentication Server or maybe I can but it is a huge mess.
You can use it… I’m not sure where I’m losing you. You can use you app as authentication provided. But you need to store the result of the authentication.
Any APP that is calling an API need to have informations stored on their side to be able to call the API. It can be an API key, client id/secret, password/email … But theses informations need to be stored in your APP to be able to call the API after.
You can use oauth2 User-Agent. You can use Manual process. But it will create a user (or something elsE) in Bubble DB to after call the API again.
Why to use Auth0?! Basically, this will be the same thing! And it will be just one more step that is not needed.
Man really you have been so helpful but i still dont get what and how i have to implement this thing. Really I work for a company that is willing to pay for some consulence on this. Would you like to do so. Otherwise I don’t know what else to do and i will drop it because messaging like this I feel like I am only get more confused while with a call it would be so easy.
I don’t have enough time actually. And it will take time to understand how your API server work and the expected process when user go in Bubble app to give a good idea to what you can do.
@boston85719 Maybe can help?
pretty sure there’s some other Bubble coach or consultant that could help. @keith maybe?
@giovanni.cassanelli
I have the requirement. I want to be able to login with google and get an idToken and my API using that idtoken as a authentication.
Hope will get sure shot solution for this.
Thank you
Hey in the end i ended up registering the users with google in bubble and creating an user in my DB (API). At the creation of the user i return the generated uuid and save it to bubble. So now every call i do i pass that Id and I return the resources of that user only.
So basically i use bubble DB as authentication.
This discussion I had with @josh24 was very illuminating and should give you a nice description of my implementation
Finally, which one authentication type in API Connector did you choose? OAuth2 Custom token or OAuth2 User-Agent flow or which other? and how Bubble does refresh token request when access token expiring?
The question is more, what do you want to do with the API? If you want your user to connect their own account, you need to use user-agent or manual auth. If you need to connect your own account only, you should choose, if possible, custom oAuth (or other private key / password, JWT… but NOT user-agent). Using user agent or custom token, Bubble will do the refresh token for you.
Actually, I don’t know if that’s possible or not. I have my own API (nodejs+postgres) and Bubble for frontend. and I want to implement 2 types of authentication: Google Auth and auth by login/password. And both of them should secure access for my API (through API Connector). I’ve read this discuss above, but still don’t understand some points. and I didn’t found complete documentation in Bubble for auth.
When user in Bubble frontend enters login and password I can send request trhough API Connector to method /login and receive access_token and refresh_token. should I store it in the Bubble storage manually or it will store automatically and automatically refreshed?
When another user authenticates using Google auth — how should it be implemented? Do I need implement it by myself on the nodejs side? or how should it be implemented? Is it possible to have both authentication for 1 endpoint in the API Connector with automatically refresh token when it expires?
I’m not sure to understand your case. What your own API is doing? Do each of your user will “also” authenticate to your own API? Or your own API doesn’t need a specific user authentication and could be a server-to-server auth? Actually, what I understand is that your user should authenticate to Bubble. Getting data to your own API is not related directly to user Auth and it could be a different API request…
I’m using OAuth Custom Token. When user tries to authenticate, enters his login and password, I send this credentials to /auth/login method and receive access_token and refresh_token from server, I save this data in Bubble for user.
After this user tries to access some methods in API with OAuth Custom Token. This type of auth by itself work with automatically refresh token by method /auth/refresh, but primary I need to pass user’s refresh_token (received from previous step) there in this API dynamically from workflow or other. I can’t find any solutions how it possible.
You are sending the request to your own server that doesn’t seem to follow oAuth2 standard. Normally, there’s not a different endpoint to refresh token, but a different request to the same token endpoint. You cannot use Bubble auth section for this case and you will need to set authentication manually using API Call and setting Authorization header in all call.
Custom auth is mostly to use with client_credentials or password oAuth2 standard
How do you get the access token actually? You probably also store this in DB?
Yes you need to refresh_token manually each time the access token expire.
Honestly, if you have created your own API service server, why not to change it to follow oauth2 client_credentials or authorization_code standard (depending of your case)?
I have <my_api_endpoint>/auth/login method, which authorizes users. When user enters login and password in Bubble frontend, I call this method and this method generates me access_token and refresh_token. After, I sign another secured methods with this access_token (by Authorization: Bearer <token>). And when my API receives requests I check token in my middleware and if token is expired or invalid API sends appropriate http code (403 or 401).
I hoped that Bubble API Connector can automatically handle it and refresh token when it necessary, but it seems like I should to it manually in Workflow for each request.
