Laravel 5.6
I need to create a way for the mobile app users to be able to register an account in a Laravel based app and then log in and gain access to the API.
All user data and credentials will be stored in Laravel App. The mobile app will have to be authorised as long as the user doesn't log themselves out manually.
I read about the Resource owner credentials grant and it seems like the only way to use username/password to receive the token. The problem here is that client_secret has to be stored or generated on an mobile app. (?)
Some people use Implicit grant for mobile app but in my case I need to pass username and password and this method does not seem to offer that.
What is the simplest, "best practice" way of implementing this basic functionality using Passport?
Related
I'm a newbie in web development. Currently, I've learnt laravel framework and be researching about passport and socialite. I'm being stuck that after logging in the application successfully by their Facebook account how users get the access token for subsequent requests.
This has been implemented using Laravel Socialite. You can follow each step to implement Laravel Socialite.
You will get the information on how to create Secret Key & Access Key for social login.
https://github.com/jd-patel/laravel-social-login
I'm developing a mobile app + SPA using Laravel as a web service. I'm not sure which grant flow will be good for this. I would avoid any third party login like facebook, google, etc. Id'like to handle user login simply with email and password. I want user to login only once on mobile app.
I had gone through some articles. I'm very confused. I found out 2 flows which might work here. 1st is implicit Grant & 2nd one is password grant.
If SPA is built inside your Laravel project you can handle user login simply with standard laravel authorization method.
For external use (mobile app or external SPA) you should authenticate users with API.
Laravel Passport mainly offers two way to handle this.
Personal Access Token
Fresh API Token
I suggest using the second one cause is the "Standard way" to consuming your web app with a nonsecure source.
Info
I'm looking for some clearification for using the Socialite package in a Lumen project. I want to use OAuth2 so users can authenticate with theire Google, Facebook or other social account on our applications.
To my understanding Socialite redirects to a page of the selected provider, asks the user for permission and return to the application with the authenticated user object. I made a base setup with a Laravel application and this all works fine.
The problem
I have an authentication API (Lumen based) where user credentials are validated. This is only a backend service. The actual user credentials are received from different front-ends (applications). Do the frontends need to implement OAuth2 / Socialite and send the social user details to my authorisation API or can the API arrange the whole OAuth2 process?
I don't quite get it how the redirection should take place in an if the whole flow is arranged by the API? There is a stateless() option available in socialite and i found some information where socialite is used in Lumen but then i don't get the whole redirect / authentication flow.
Options
Different optios
Like to hear from users if this option is possible, hope my question is clear. :)
Just to update on my own question;
After some research i found the flow to be like this:
-> Frontend handles the user request to be authorised by Oauth2 with a specific provider. (we get redirected to a page of the provider asking about permission for this application). This can be done with socialite (in case of Laravel) or any other package for a specific framwework.
-> An Access token is received by the frontend and send to our Lumen backend service. Here we can use Socialite again to get the user details for this access token. The user details can then be used to create a new user or attach a social login to an existing user. When access token is valid and user is created or found in existing user, the user can proceed in the application.
Hope to help someone in the future with the same questions :)
Trying to get my head around the Identityerver4 setup for my project. I have a mobile app where users should be able to login with either facebook or username/password. Facebook login is implemented using the native facebook if available on the device. This results in a token from facebook. With this token I want to request an access_token and refreshtoken (hybrid flow) to access my api (resource). At the same time, some users will also log in unsing username and password.
As I need some info about the user, my plan is to user ASPNET Identity but I'm not sure how to make it wotk together with IdentityServer and If user profiles should be created in Identity based on both logins (registration). It seems obvious for the username/password login, but what about my social facebook login. Later there might also be a web client. So my basic question is how to handle the user registration with both setups
I have an app idea and need to implement authentication. Because of the nature of my app, I only want linkedin users to be able to access my app.
After reading a bit about spring oauth / spring social / etc, it seems its definitely possible to use something like Linkedin to access MY app. I want a user to see linkedins login button on the first view of my app, create my own version of this user in my app, and then allow the user to use my app.
After my findings I have found the generic flow
*user authenticates via social login button
*client app redirects user to service provider to receive a token
*client uses token and makes another request to service provider to receive auth token
*now my client app can make calls to service provider with auth token of user(this is the part where I am a bit confused)
*I want to use this token to validate calls against MY api NOT linkedins(is this wrong)
I don't really care to make calls to Linkedin on behalf of the user(except to pull user information). I ONLY want linkedin auth so that I know that users who use my auth are valid linkedin users. I thought something similar to Tinder where you MUST have a facebook account, I want to copy that design but couldn't find any hints from google. It seems the examples I find online all use the social login to ultimately use the service providers API.
I also read some stuff about SSO which sounds like what I want, but I definitely plan to add at least 1 more social login down the road. My clients will use a browser or mobile app.
I guess the main question here is once I authenticate a user using social login, am I supposed to use his existing connection to make calls to my API or create a new connection somehow. My goal is when a user does a social login, he now can access MY app, I want to reuse their existing connection without authenticating them into mine(only store their info). I want to follow best practices.