Correct me if I'm wrong or someone can give me a guide about this. I'm working on an Ionic app with Laravel as a backend REST API.
A User can log in with credentials (email, password) or with Facebook.
Of course I wanna protect some states in the App as usual, and searching and reading in the web came across with JWT.
The thing is I'm little confused about how Facebook Oauth and JWT are working together.
So, here's what I'm trying to do:
If a user logs in with FB, get the id, nickname, email and creates a user with this information, also insert into a table this credentials from facebook so when it logs again check if the user already exists.
Then, this new user gets access to the app via JWT from the server, am I right??
Or how the auth token from facebook causes problem with the jwt token?? Or it will not??
Am I doing too much to resolve maybe a little problem?? Or is just the tip of the solution??
Thanx for your support.
The tokens shouldn't conflict. The process should be the "same" in both cases - the jwt is generated from an user instance/model.
How you create/get this instance is not important - from credentials, facebook token, cookie or what ever you like.
The jwt just includes an unique identifier - the id.
Related
I've read on various blog posts that a REST API does not require a logout endpoint.
Instead, the front end should just invalidate the token.
I'm using Laravel Sanctum, is this applicable to that?
Could someone explain why the session does not need invalidating on the server? If the token on the server is not invalidated, is there not a chance that a new user could be given the same token and access another user's details?
"is there not a chance that a new user could be given the same token and access another user's details?"
no mate, not a chance. because you must generating token with user information, in other words you are "attaching" a token to specified user. you can check this if you want.
I am using Laravel as my backend together with Sanctum which generates personal access token for mobile users. For my mobile application I am using flutter.
To authenticate users they login with their username/password and get a personal access token in return. This works but requires a user to login every time they open the application again so I did what most tutorials suggest which is saving the token on the mobile device using shared preferences/secure storage.
Now comes the question how do you invalidate a user when you remove their token from the backend? On initial login it appears everything is still fine because like in most tutorial I check for the existence of a token. After that whenever I want to make a request which uses the token I obviously run into problems because it not longer exists on the backend.
Most tutorials/guide suggest saving the token and using that a reference to see if the user is logged in or not but this seems flawed because it gives the false impression you actually have a valid token.
My guess is this can be solved by always performing a heartbeat/ping action to check if the current token is valid and if not send them to the login screen instead of simply checking for the existence of the token.
Thoughts on this?
I can suggest a hack or trick here in every launch of the app you can send a request to an API to check if the user's token is valid or not and if it is valid then you can continue the app otherwise force the user to login and generate new token this way your app will be secure via server / API.
For this, you can store the user's secret token in the database and check it via HTTP API call and send a response from the API accordingly and check the response in app and do the next operation according to the response you get.
I don't know if this is a great way of doing this job but it is a kind of hack/trick to achieve what is needed.
Thanks
I'm creating an API server which will be consumed by a mobile app that I will work on later. I have yet to see any reference of API best practices related to user flow and returned data even after searching for several hours.
My question is whether the login response of an API should return the a personal access token with the refresh token along with the user info? Or should I just return the token and make another API call for getting the user info.
I could just do what I have in mind but I'm trying to learn the best practices so that I don't have to adjust a lot of things later.
I need suggestions as well as good references related to my question.
Thank you.
It depends on what you are using for your authentication. If you are using libraries like Laravel Passport or JWT, you can have the token endpoint which returns the access token, refresh token, validity period and the token type (Bearer). You can then have an authenticated endpoint which will be used to get a user's profile based of the token passed in the request header.
However, if you go through the documentation for those libraries, in most there is an allowance to manually generate a token. You can use this in a custom endpoint that will return the token as well as the user profile Passport Manually Generate Token.
If you are using JWT, you can also embed a few user properties in the token itself. The client can the get the profile info from the JWT itself without having to make a round trip to the server. Passport ADD Profile to JWT
If you have a custom way in which you are handling authentication, you can pass the token as well as the user profile in the same response.
In the end, it's up to you to decide what suits you best.
Have you looked at OpenID Connect? It's another layer on top of OAuth 2.0 and provides user authentication (OAuth 2.0 does not cover authentication, it just assumes it happens) and ways to find information about the current user.
It has the concept of an ID_token, in addition to the OAuth access token, and also provides a /userinfo endpoint to retrieve information about the user.
You could put user information in your access token, but security best practice is to NOT allow your access token to be accessible from JavaScript (i.e. use HTTP_ONLY cookies to store your access token).
everyone!
First, sorry if such issue is already was. And sorry for my English...
I am newer at laravel and I like it.
Now I learning how to create REST API app and for this I use laravel/passport.
And my target is to make social networks authorize via API. How it should work:
Client app, for example - mobile app, must send me (my app at laravel) request with Google token (for example).
From receive token I get the data about user, save it or find already existent.
After that I must send a token (from my app, not Google one), refresh token and expires_at.
Of course in normal api auth I use password_grant where you must do request with login and password, and it generate token, refresh token,expires_at. But how to do it if you have not password? How to create token, refresh token and expires_at for special user?
I know about personal tokens, but it only 'longlive' token? It make no sense! Why is not exist personal token that go with refresh token and expires_at or password token where you can create it directly?
Is there are some right solution? Will be solution in a future version of laravel/passport?
I will be very thankful if you can advise some really good solution.
I'm using hybridauth library.
Hybridauth documentation says persistent sessions possible by storing the session data.
Lets say I stored users session data in my database. It contains oauth token, oauth refresh token etc..
Using oauth token, its possible to contact oauth server without asking user permissions.
Now everything fine so far. Now how exactly login the user automatically if the user logged into google?
I mean do I have to use any cookies?
I can't specifically help you on that library you are using, but have you looked at this? https://developers.google.com/accounts/docs/OAuth2Login
If you do an authorization for login as well, you'll get a token back and you can use that to get the userid of the user at Google
This field is only present if the https://www.googleapis.com/auth/userinfo.profile scope was present in the request for the access token. The value of this field is an immutable identifier for the logged-in user. Store this and you should have a durable identifier of the user.