I'm creating a react native app and adding instagram authentication to it. I want users to be able to "add" their instagram accounts to their main user account, so I have a "connect your instagram" button.
I have this working on my web app fine.. The flow is as follows:
User clicks 'connect instagram' button and a new window opens and is directed to https://instagram.com/oauth/authorize/?client_id=xxxx blah blah
User authenticates and instagram redirects to my REDIRECT_URI with a CODE parameter
My API server takes the CODE parameter and sends a post request to instagram with all the credentials.
Instagram verifies this information and gives me the users ACCESS_TOKEN
Can someone tell me how this is supposed to work in an app?
What's my REDIRECT_URI supposed to be? The server api?
Is it the same flow as my web app? If so, how do I get the users back to my app after the window is closed. How does my app know that the user now has an access token?
With a native application the flow is similar to what you described for the web application.
The Auth0 Mobile + API architecture scenario describes what should happen when you need to authenticate a user for a mobile application and then later access an API on behalf of that user.
Summary
you will continue to use the authorization code grant;
if the authorization server in question supports it you should use the PKCE (Proof Key for Code Exchange by OAuth Public Clients) for added security;
you will need to select how you will receive the code in the native application; you can use a custom scheme com.myinstaapp:, a local web server with the http: scheme or a few other options; (see this answer on OAuth redirect URI for native application for other alternatives)
you exchange the code obtained by the native application with an access token in a similar way to what you would do for a web application; (except for the use of client secrets which are in general not useful for native applications as they would be easily leaked)
Additional Information
The flow described in the Auth0 scenario assumes that authentication will happen through an OpenID Connect compliant flow and in addition you'll get the access token as specified by OAuth2. I'm not overly familiar with Instagram so if they only support OAuth2 that part is of course not applicable.
Related
I am creating an application with a React front-end and a Java Spring Boot back-end.
My login flow looks like this:
A user clicks on login on the front end
User is redirected to the Google Oauth authorization endpoint on my server
OAuth 2.0 Authorization flow happens: User is redirected to Google and logs in. Google interacts with my server first exchanging an authorization code and then a JWT access token. My server now has the JWT access token for the user.
ISSUE: I now need to redirect the JWT token to my React front-end so that the token can be saved and used every time the user wants to request access to a protected resource on my server.
Is there now an industry standard/best practice for redirecting the token to my React front-end from the server?
There are similar questions on this subject on Stack Overflow, however they are at least 3 years old, e.g. How to provide frontend with JSON web token after server authentication?
Since then the implicit flow has been deprecated, storing JWTs in local storage is no longer recommended, and https://datatracker.ietf.org/doc/html/rfc6750 explicitly discourages passing bearer tokens to the front end in a redirect URL.
I was wondering if anyone knows of an up to date solution for this problem.
There's a draft IETF BCP for OAuth 2.0 for Browser-Based Apps - see here. Basically, it's very similar to native mobile apps using authorization code with PKCE (proof key for code exchange).
FWIW I agree implicit flow shouldn't be used, but IMO you shouldn't be using authorization code flow without PKCE, as this flow is for server side rendered web apps.
EDIT - Auth0 (one of the most popular CIAM solutions on the market) docs say the same thing - see here.
If the Client is a Single-Page App (SPA), an application running in a
browser using a scripting language like JavaScript, there are two
grant options: the Authorization Code Flow with Proof Key for Code
Exchange (PKCE) and the Implicit Flow with Form Post. For most cases,
we recommend using the Authorization Code Flow with PKCE...
Don't.
You seem to mix 2 issues here.
First, you would like to use OIDC for authentication in your SPA. For this you would use OIDC Implicit Flow or Authorization Code Flow with PKCE.
Second, you would like to delegate authentication to google instead of doing it yourself. Basically this is known as federation - you trust external Identity Provider.
The full-blown version would be to setup your own Identity-Provider server (like e.g. keycloak) and configure federation to google there. Your SPA would initiate OIDC against your Identity Provider and wouldn't even know that google did the authentication. You could also easily add further Identity Providers (e.g. facebook) if necessary.
An easier workaround would be to initiate OIDC login from your SPA directly to Google. This way your SPA would receive token directly from google and you would need to protect your own backend as a resource-server accepting and validating those tokens. Adding further Identity-Providers like facebook would be a challenge.
i am trying to add authentication to my app using OAuth2 & also secure the back-end so only logged in users can access it.
Im just trying to wrap my head around the process and some clarification would be great. To my understanding here is how i would do it.
User logs in with oauth2 provider in app.
App sends the returned code to the back-end.
back-end fetches access token and returns to the app to be saved.
now, for all secure requests. I send the accesstoken as a parameter to the back-end which checks if it is valid or not.
would this be the correct way of creating a secure dashboard type app with oauth2?
thankyou.
It's correct except that in step 2 you send the authorization code back to the OAuth2 provider - as part of an authorization code grant message.
Here's an example of the message workflow during a user session. For a mobile app the same OAuth messages are used:
https://authguidance.com/2018/01/18/desktop-app-technical-workflow/
If it helps there are some code samples of mine to demo this behaviour - it is tricky to implement though:
https://authguidance.com/home/code-samples-quickstart/
I have a question more related to the way OAuth 2 is working but since using IdentityServer to implement OAuth I think it's relevant. I could not find an answer anywhere.
I'm building a website and a mobile app that consumes my own API. Each user of my app will have a username and password, that will give him access to the app/website and though the API to his information.
I'm not sure about the right way to handle the flow for user login:
On the website I have my own designed login form. I don't want to move the user to my auth server to login, and then have him approve the information he gives - he is the user on my system - I have access to all information - kida like facebook has a login and access to the informatio - they don't ask what you're willing to give them. So is implicit really the way for this?
On the mobile app I also have a login form and now I read here (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-10) that the OAuth approach is to have the login in a WebView?? Doesn't look like facebook login is in a WebView on their mobile app.
The approach I was first lookin at is the Resource Owner. Users will login, get the token and the refresh token and can start working against my APIs. But storing my client_id and secret on the mobile app? on the website javascript files? doesn't feel right. I can of course make a call to an API that will mask those and be a proxy to the login process... but... (read #4).
In the future I would like to allow access for third-party developers. For them to allow login for users of my system I will use the implicit flow. Also, I plan for those developer accounts to have restricted API access (for example, the number of calls to the API will be limited by plan). What prevents those developers from asking for the username and password of their account on my system on their website, getting the response from my servers with the access token and refresh token, and using my API however they want, without restrictions, and having access to the entire user profile?
Lets say I'm sticking to the resource owner flow, receiving back from the server a token and a refresh token. What should I store on the mobile device and how? What should be stored in the browser and how? the refresh token? and each time he opens the app get a new updated token with that refresh token?
Edit
Just to clarify, because I find a lot of lectures and articles that explain the process from an API consumer point of view (ie. the third-party developer): I am the API owner and the auth server owner, I'm the owner of the user accounts (they are my users of my services), I'm also my own consumer (though the website and the mobile app), and in the future I want to enable third-party developers to allow my users to login with their accounts of my service (kinda like Facebook or Google)
You're correct that you shouldn't store the client_secret in your app, but I doubt you will get around storing the client_id. You could disable the consent screen for your app as well, and build a native login view. You need to store the access_token and the refresh_token on the device (maybe encrypted in a database) if you don't want the user to login everytime they use your app.
As for problem 4, you could do the following:
Embed the client_secret in your (web) app
Set up which hosts have access to your api on the IdentityServer
The IdentityServer generates a salt and sends it to the client
The client calculates a session_secret using hash(ip_address + session_salt)
The client uses the session_secret and the client_secret for the API call
Server validates the hash and client_secret
It's nearly impossible to completely prevent someone from using your API. But you should add various rate limiting methods, such as limiting IP addresses, API calls etc. But nothing will stop someone decompiling your app and accessing your client_id.
I am creating an android app that has access to an online Database. The initial app activity screen is a login form where the users credential are validated. If the credentials are valid then the app continues to the next activity. I've looked at OPENID and a few others methods. How would I implement OPENID or a another form of user authentication for my app. I would ultimately like to have a third party take care of user authentication and credential storage.
Have you tried looking at OAuth?
http://oauth.net/
OAuth Signpost is an android implementation of OAuth
http://code.google.com/p/oauth-signpost/
Server side, you need to provide an OAuth ready API, if your server is PHP, take a look at
http://code.google.com/p/oauth-php/
My app is architected as follows: I have a web service (running on GAE, not very relevant to this question) and the data that this service contains is made available through a website and through mobile and desktop apps.
Currently, the user authenticates to the website via Google ClientLogin and the apps authenticate/get authorized via GAE's built-in oauth provider. (OAuth is being used here mostly for authentication, my app doesn't actually use any external data via OAuth other than the user's unique ID and email address.)
What I'd like to do is expand the number of services that users can use to login. Because of the complicating factor of the apps, it seems I need OAuth. But I can't really properly conceptualize how this flow should go.
Lets take Facebook as an example. When a mobile app goes through the Facebook oauth flow and acquires an access token, this isn't enough - because its my service, not the app, that actually needs to talk to facebook to retrieve contact info and a unique user ID. This leads me to think that the OAuth process needs to happen in the context of my service, and not the mobile app. My service then becomes the consumer and Facebook the oauth providor, and the service holds on to the oauth access token, this happens when a user sets up their account for the first time.
If this is the correct approach, where does that leave authentication for the apps? What happens when the user already has an account and installs a fresh instance of a mobile app? I imagine also going through the oauth process, matching up credentials with the data already stored by my service, and then issuing my own "access token" to the app from the service, to authorize that instance of the app. This seems convoluted and hackish.
I'm sure I can't be the only person who is in effect "borrowing" the account system of a third party for a mobile app with a backend, but I really don't see what the proper way to do this is.
What am I not seeing and/or getting conceptually wrong?
A few colleagues and I once did a project quite similar in nature, back in university. We authenticated our users through either Facebook or Foursquare, using their respective OAuth APIs.
The native Android version of the app opened up a WebView with the OAuth provider's start page, which redirected back to our service after authentication. Then our service did a request for the OAuth token from the OAuth provider (Foursquare has some pretty simple instructions). When we got that token, we set up a session using cookies, which we could access from the app.
To validate sessions, we just checked whether the access token was still valid with the provider. We also used the respective providers' unique user IDs to distinguish users.
So yes, what worked for us is: Make the app authenticate & authorise your service, not the app itself.