I'm building an application with react as frontend and a rails API where im using google oauth2.
I currently have 2 possible approaches in regards to how to handle to response from google:
The client is redirected to the google authentication page from the frontend and upon return the user is redirected to the API URL with a callback.
The client is redirected to the google authentication page from the frontend and upon return the user is again returned to the log in page where the response is sent to the API.
I've read here on StackOverflow. Some saying it's okay practice and architecture to have client side redirects in your API while some disagree. Which one is it?
Related
I have a Nuxt application that interacts with NationBuilder, a 3rd party application. In order for users on my site to interact with data from their NationBuilder account, my app must allow them to authenticate over OAuth with the NationBuilder API.
The first step of this OAuth process works fine; My client sends a request to the NationBuilder API's /oauth/authorize endpoint. The browser redirects the user to NationBuilder's website where the user can login to grant my application access to their NationBuilder data. Then, NationBuilder redirects the user back to a second page on my site with query parameter in the URL containing what is called the "code". This second page on my site hits our internal API with this code, which in turn hits the Nationbuilder API's /oauth/token endpoint with the code to receive the access_token. Now we can use this access_token in any call to the Nationbuilder API.
The issue I'm running into is that when Nationbuilder first redirects the user to that second page in our Nuxt app, the reloading of my site takes a while and seems to be skipping some initialization configuration steps. I think this is the case because some of the functions that normally work when I boot up my site are not found.
I am in the process of developing the application, so I am running my site on localhost and using ngrok to create an https tunnel to satisfy the NationBuilder API. Maybe this issue is related to the tunneling?
I have a hunch I should be doing this all differently. If there is a conventional way of authenticating a Nuxt application with a 3rd party application over OAuth, please point me to an example/docs.
Cheers.
I have a web app front end and web api back end both written in ASP .Net Core 1.1 MVC. I am using Auth0 as the authentication server, using the "authorization code grant flow".
So the user logs in - i.e. the user gets directed to Auth0's login screen, which, if the username and password were correct, sends the web app back an authorization code, which the web app then exchanges for an access token, which is then used for all web api calls.
Then, the user clicks on a link which makes the web app call upon a web api action. My question is, how can the web api know which user is making the request? Or maybe at the point the user successfully logs in, the web app should call upon a controller in the web api and tell it which user just logged in? Not sure what the best practice is...
Thank you
I will answer in terms of OAuth 2.0 specification.
Specification determines 4 roles:
Resource owner
Resource server
Client
Authorization Server
In your context:
Resource owner is end-user.
Resource server is your Web API.
Client is your web application.
Authorization Server is Auth0.
Follow steps:
Your Web API should be registered on Authorization Server
(https://auth0.com/docs/apis).
Your Web API should be responsible to validate access tokens that
are used for requesting API. This access tokens contains info about
end-user/client (https://auth0.com/docs/api-auth/tutorials/verify-access-token).
You should include Web API scope in authorization request.
You should get access token in your web application and include it in HTTP request to Web API.
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.
I am creating a mobile application which will talk to my REST Web Services, for login, GET, POST, DELETE and logout. I have been trying to figure out how to secure these REST Web Services using Keycloak. I do not want any In Browser Login on the mobile application, so I was inclined towards Direct Grant API and Admin REST API for authentication and token validations. But, now after looking at the available options on Keycloak, every request from the mobile app must be intercepted, and then make a REST call to the Keycloak module for validating the token and then return a response back to the mobile app.
Is there a better way in doing this? Some inbuilt function calls to check the token validity instead of making an HTTP call for every request from the mobile app? I think this is a huge overhead.
My server is on JBOSS. Spring, Resteasy and Keycloak-services are being used to figure out a solution for this problem.
I own both, an API backend at api.example.com and a frontend single page app at example.com . The API is basically a wrapper for a database backend.
Now, I want to have a user of the single page app (= client app) to authenticate with the API. For this, as far as I understand, the client (= single page app) sends a client_id together with a user_id to the API, and the API then gives out an AccessToken.
However, in my single page app, I am not sure where/how to store the access token. I am looking for a simple reference, or a good concept to have a logged in user access the API application.
A friend suggested me this flow:
The client displays inputs for login (be it e-mail or username) and password,
The client app makes a request to your API to obtain an unauthorized token (e.g. POST /api/v1/auth/new),
The server creates a token for the app and sends it back,
The client app sends the token along with the login, password and request signature to the API (e.g. POST /api/v1/mobile_authenticate),
The API validates and verifies the credentials,
If everything is OK the app uses the token to make further on the user's behalf.
Any thoughts? How can this be simplified or improved?
I'm using the api key for the permission check in the server API. The workflow how the api key works is as below.
The client app displays inputs for login (be it e-mail or username) and
password.
The client app makes a request to the API to obtain an
api key (e.g. POST /api/v1/users/validate).
The client app accesses the API with the api key. (If it is the http request, the api key can be included in the http header or query string.)
Hope it helps.