Hi, we are looking to add authentication to our Ap...
# support-questions
d
Hi, we are looking to add authentication to our Apps (web and mobile) using SuperTokens. I see you specify that you dont support mobiles native but we were wondering if maybe we could still implement it with SuperTokens backend? Something like the mobiles will authenticate with social providers and send to the backend the provider token for us to authenticate with the provider (using client id and secret) and sign in/up a user and return back to the mobile a supertokens user token they can use to access our API. I hope i was clear enough but if working with mobile native isnt an option at all with supertokens from various reasons like security etc pls let me know.
r
hey @Diesel
We do have an android and a react native SDK. What we don't have yet is an iOS SDK (it's a little outdated).
However, you can still use us by slightly customising the session flow we have.
d
oh ok could you share any guide maybe? any help would be helpful. I dont see anything in the docs for mobile native only react/js. also about the part of customising - do you mean the mobile or just IOS?
r
I mean for all the clients that you have So the way our session flow at the moment is that we issue an access and a refresh token to the frontend as cookies. The access token is used to query the APIs, and the refresh token is used to refresh the session when the access token has expired. The refreshing part is something the frontend SDK handles. Now since the iOS SDK, is outdated, you will need to change the session flow to be simpler - to issue just one token which you can save on the frontend and use on each request. This will also affect how your APIs do session verification. The idea here is that you override all the session functions (createNewSession, getSession, revokeSession etc..) to work with just one token. For example, in the createNewSession, you could now create a simple JWT (using Session.createJWT function that we have), and attach that to the response body. Then when you call the sign in function from the frontend, you will get back the JWT you created. You will have to override the getSession function as well to read the JWT from the request body and verify the JWT. And so on.. If you want, I can make a quick demo app that uses nodejs on the backend to showcase the customisations.
d
I see so basically we would need to enable the JWT tokens instead of the sessions and save the token in the clients instead of using cookies? Yes, if you could share any example that would be amazing. Also a link to the android and ios sdks?
r
Yea. https://github.com/supertokens/supertokens-android iOS SDK is private since it's very outdated
I'll make an example app sometime today and share here.
d
Thanks. We will look into the SDK. Im still not 100% sure on the flow of things in the mobiles which API of the backend they need to call.
r
Right yea. So the set of APIs to call on the backend are here: https://app.swaggerhub.com/apis/supertokens/FDI
which shows you which APIs to call
d
ye i got it open ever since i started working with supertokens. but the flow when you call which api is still very confusing 😅 I will check out the example you sent thanks.
r
I'll send a link to the demo app shortly.
hey @Diesel
Here is the demo link: https://github.com/supertokens/supertokens-auth-react/tree/master/examples/with-jwt-localstorage Using such customisations, you don;'t need to use our frontend SDKs at all. And can use us on mobile devices and any frontend client easily.
d
thanks im checking it
hey @rp I went over the example thank you for that. I got several questions: 1. Using this approach we are losing the way to use refresh token with access token? is there a way to keep the refresh? 2. Connecting to the first point, revoking token is an option here or we basically would need to wait for the jwt access token to be expired? 3. Using a social login in the clients they will do all handshake with the social provider (google, facebook and apple in ios) and will send the code to the backend API auth/signinup to sign in/up the user? 4. Connecting to 3 the web client will have to do the sign in to google on their own too? cause so far in the demo i made there was an option to configure the client id and secret of google in the backend and redirect the oauth in google to the web client. Is this option will not be available now? like specifying multiple Google providers in the backend?
r
1. Yes, we are loosing that feature. If you want to keep this feature, you probably just want to use our inbuilt session management, but for that, you will have to wait for us to update our iOS SDK. Or you can contribute and update it yourself (we can chat on DM if interested) 2. Would need to wait for JWT to expire. You can implement JWT blacklisting on top of what the demo app does, here is a blog about this: https://supertokens.com/blog/revoking-access-with-a-jwt-blacklist 3. Yes. They will send the authCodeResponse and not the code. For mobile apps, you get the result of the code exchange directly on the frontend. 4. You can use multiple google providers on the backend and the web flow can be different than mobile flow. You may want to pass the
isDefault: true
config for the providers meant for web flow. And then for mobile apps, you can also pass in the client ID in the request which will help it identify the right provider for it.
d
Wonderful thank you so much for the help 👌 Right now seems like we decided to go with web option in the apps instead of native so this will simplify stuff for me and we can keep the session flow.
r
cool!
3 Views