CODEWITHSUNDEEP
laraveloauth-2.0authorization
Jules
Jules

Reputation: 107

Laravel Passport APi - Implicit grant

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:

  1. Log in with a user by a username and password via html/javascript to laravel (Angular) via an ajax request.
  2. Get an access token to communicate with the api
  3. Do some action in the spa that triggers a request to the api using the access token
  4. 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.

  1. Log in to laravel via a default blade login form (did not create one using ajax yet)

  2. 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);

    });

  3. The redirect shows an approve or deny authorization request screen (this is not what i expect)

  4. 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?

Upvotes: 1

Views: 3634

Answers (1)

Evans M.
Evans M.

Reputation: 1951

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

Upvotes: 1

Related Questions