I am trying to think of the best way to implement the oauth authorization code grant in my API codebase.
I cant use the standard routes passport generates because I have no frontend so I can't create sessions or anything to store user data/codes etc...
Instead I was planning to use the following workflow -
User redirects to frontend (seperate codebase) https://{frontend}/oauth/authorize endpoint passing through the require URL params (client_id, redirect_uri)
Once this page is hit a request is made to my backend system, this checks to make sure the client_id and redirect_uri match a record in the database. A success response is returned if a record exists.
On the frontend because the backend response was a success they can now enter their username and password, a request is made to my backend system again to check these details are correct. If everything is correct the backend returns an auth code in the response data
If the login response was successful the frontend redirects the user back to the callback URL with the code url param
External app then makes a request to https://{backend}/oauth/token which checks the code and if its a success returns an access_token, refesh_token and expires_in
My question is does this flow look correct for an app with seperate frontend/backend codebases. Just to clarify my frontend codebase is using the laravel password grant which is working fine so this question is only for integrating external systems via oauth.
I was also wondering when the backend generates the auth code where should this be stored which can then be checked again when the /oauth/token request is made?
Related
I have more conteptual question, how exactly should I handle social login in my project.
The use case is that I would like to allow user to login with Facebook, and keep on my backend information about this user (email, firstname, lastname)
I have some proposal Flow, but I'm not sure if it's a proper approach.
Let's say that I have application architecture as above. Now I would like to explain step-by-step full success flow.
Client (Vue application) make a call to AuthProvider (Facebook)
AuthProvider returns access_token
Client after reciving access_token make a call to backend endpoint like /fb_profile with access_token and userID (?)
Backend make a call to AuthProvider to check if given by client access_token is valid or not.
AuthProvider returns information about user. Backend after getting information about user, save it to database and generate new JWT token
Backend returns generated token to user
Now my question is - Is this good approach? Or should i handle it in other way? Like keep more logic to backend part? Instead of make a call to Facebook from Client, maybe should I make a call to backend, and backend make a call to Facebook?
You seem to be on right track. There could me many ways to do the same thing, here is the way which is working for me using vue/laravel/passport/socialite/github.
Trigger redirect in controller from frontend,
Provider(here github app) is triggered in browser with its url using client id/app name saved in back end config/env. Fill out your login details
It will redirect as created in provider and configured in backend-> show it on frontend, in my case its
http://localhost:8080/authorize/github/callback
From frontend now trigger callback in controller, it will check if user details already exist and will insert if its first time user as per logic. Then it will send back access_token to frontend which can be used in frontend for all the operations
DB
The above will be the sequence of the request flow ( same as yours ).
This would be the standard practice we used to integrate with Facebook. In this case, I strictly advise you to use the JavaScript SDK for Facebook.
Refer below link in case if you run into the following issue:
Vuejs component wait for facebook sdk to load
I am implementing an oauth2 authorization server for providing access to our apis.
Our application is a single page application, with the a jwt token in the authentication header to provide access.
We want to setup an oauth2 Authorization Code flow like,
User is on external site and wants to get access to our apis
External site redirects to our site/spa with oauth2 params, client_id etc.
SPA checks authentication, users needs to login to continue
User sees page for confirming access
User confirms access, code is returned and redirected to external site
External site does backchannel call to obtain token from code
My problem is in 4 and 5, in standard Spring setup this is provided by
org.springframework.security.oauth2.provider.endpoint.AuthorizationEndpoint,
on /oauth/authorize GET oauth params are stored in the session and the confirmation page is shown, and on post of that the code is returned in the redirect.
But I cannot find any guidance/examples on how to do this with a page hosted in a SPA.
You have to be authenticated in this endpoint and I cannot really use the top level page that /oauth/authorized provides because we use header based authentication on rest api calls only, all our top level calls are unauthenticated.
Is there some obvious way to make this work?
I think I do not want to put my authentication token in a cookie.
I was thinking of just then creating a controller that sort of does what the AuthorizationEndpoint does and returning a redirect to the redirect in Javascript. But I am not sure if I would be breaking some other security requirement.
I want to build a spa via angularjs and use laravel as a api for the spa. Reading trough the docs of laravel passport i discovered that i need to use the implicit grant for this purpose. But i am not really sure in how it should work from front to back. I just want to have the ability to log in a user with a username and password and then just use it and i need some clarification on the process. This is what i want:
Log in with a user by a username and password via html/javascript to laravel (Angular) via an ajax request.
Get an access token to communicate with the api
Do some action in the spa that triggers a request to the api using the access token
Getting data back from the api in response to that request.
But what i see now with the implicit grant i a bit different than what i expect.
Log in to laravel via a default blade login form (did not create one using ajax yet)
Redirect to oauth/autorize like this
Route::get('/redirect', function () {
$query = http_build_query([
'client_id' => 'client-id',
'response_type' => 'token',
'scope' => '',
]);
return redirect('http://your-app.com/oauth/authorize?'.$query);
});
The redirect shows an approve or deny authorization request screen (this is not what i expect)
When i approve the request, the browser redirects me to the redirect uri that is specified in the oAuth client database entry with the access token. And i should be able to.
What confuses me even more is the fact that i seem to need a new client for each laravel user. I expect to have 1 oauth client representing my spa that can access the laravel users. Could you please clarify this?
If you are going to use a password grant in a JavaScript application then you must use a server side proxy to do the authentication and secure both client_secret and the refresh token.
The proxy manages the whole api communication process or just the authentication part and returns a short lived access_token . Authentication state is managed via a server session. Some requests must be protected from CSRF exploits depending on your implementation since most implementations use a cookie.
Otherwise use an implicit grant to authenticate your app. (See links below for more info)
https://auth0.com/docs/api-auth/tutorials/implicit-grant
https://oauth2.thephpleague.com/authorization-server/implicit-grant/
You can refresh your access token using silent authentication as described here
https://auth0.com/docs/api-auth/tutorials/silent-authentication
NB: In most cases refresh tokens do not expire, that's a big NO for Frontend storage.
Client Secret should always be kept secret.
Edit (2020)
It's now 2020 and a lot has changed in the web security world.
There are known vulnerabilities with implicit grant especially since your access_token can be intercepted mid-flight and redirected to another server.
It's now recommended to use PKCE flow instead of implicit grant
Okta has a very nice article and video regarding this Is the OAuth 2.0 Implicit Flow Dead?
Laravel has also released a much simpler alternative Laravel Sanctum I suggest you have a look at it as it uses secure HTTP only cookies for access token storage and also implements CSRF protection out of the box
Some background:
I am writing a small SPA that will use a back end that I have also written. The JS and the back end API are on the same server.
i.e. SPA will load from foo.com, back end is at foo.com/api
In the past I have always used Spring Security with simple form based login. After logging in the user will get a session cookie. Pretty standard stuff.
For this app I looked into OAuth2 implicit flow. My understanding is the User would load my page, then from the SPA I would direct the user to the authorization endpoint so my app could get a token. The user would be redirected from the authorization endpoint to a login form. After the user authenticated with the form.. they would be redirected back to the authorization endpoint to get the token and possibly grant access to the JS client. After that the user would be redirected to a URL specified by the client, with the new access token as a URL fragment.
I have this working and its all great. The part I don't quite get is this:
When the user is redirected to the login form and they authenticate a session is created on the server that has to at least last long enough for the user to be redirected to the authorization endpoint to get the token. At that point they already have an authenticated session on my server, why not just stop there and use traditional cookie and session based logins?
I have a Spring (3.2) based web app that a user can log into. The site will also provide an API secured via OAuth 2.0. My question then, is how do I go about generating a token for a logged in user?
The underlying idea here is that there will be a mobile app that opens up a web frame to the login page, which will eventually redirect to a url schema with an oauth token that the app will catch and then use for the api calls. Looking at the code for TokenEndpoint, I see that it defers token creation to a list of TokenGranter types. Should I be creating my own TokenGranter extended class, or am I looking at this all wrong?
I ended up writing a controller like this:
OAuthClientRequest request = OAuthClientRequest
.authorizationLocation(csOauthAuthorizeUrl)
.setClientId(csClientId)
.setRedirectURI(
UrlLocator.getBaseUrlBuilder().addSubpath(AUTH_CODE_HANDLER_URL).asUnEscapedString())
.setResponseType("code")
.buildQueryMessage();
UrlUtils.temporarilyRedirect(httpResponse, request.getLocationUri());
return null;
Then handling the code returned. My big problem here was that I had the /oauth/authorize endpoint set to use client credentials. Once I realized that tokens were being issued for the client ID instead of the user, it started to make sense.
So you want to use the Authorization Flow of OAuth. Spring has already support that, if you have configured the spring-security-oauth correctly, you just have to redirect the user/your mobile apps to /oauth/authorize?client_id=xxx&response_type=code this will redirect user to authorization page, if user has not login yet, it will redirect the user to login page then to the authorization page.
After the user completed the authorization process, it will redirect the user to an already registered redirect_url parameter with the authorization_code 'yourapp.com/callback?code=xxxx'.
Your application should exchange this authorization_code with the real token access to /oauth/token?grant_type=authorization_code&code=xxxx&client_id=xxxx&client_secret=xxxx
After that you will receive the token access that can be used to access the resource server.