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.
Related
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).
I'm creating a SPA app with Vue.js (will be stored on remote server) and I'm confused as to what I should use.
At first I considered the use of Passport, but I don't understand how to make an API with Passport for 1st party only. Also I don't understand, how to make it quite secure if I need to send to the server my client-secret and client-id.
Then I read more about JWT, but there's no scopes for my tokens and no refresh tokens. It means if somebody stole the token from localStorage, then he will get access to this user permanently.
And one more question about the token access and API. I read a lot about different token expiration when it depends on its importance. It means token for changing password must be valid for a period of 5 minutes, but token for reading some information should be valid for 6 months. Is it right and how to do this right?
About JWT or Passport - what should I use then?
If you access api directory from client(using angular/react/vue js..) I suggest you to use Passport. in the passport there is a option call Password Grant Tokens, so user have to enter user credential and it'll generate a token(you can adjust the lifetime of the token) and when it expire you can refresh it. And yes if someone stole your token they can access your data
Read this if you want to know more:
https://stackoverflow.com/a/34983109/801448
My project has the requirement to access the yammer data using the given REST API using server side script(mainly PHP) and not involve a client side login using yammer's OAuth dialog.
I have gone through this document:
https://developer.yammer.com/docs/oauth-2
but this says, we requires user interaction.
What I wanted was can I generate a client_id and client_Secret to further generate access token to make API call out, but in all these processes I only use the authenticated users username and password in my server-side script.
Can anyone suggest a solution or is a client-side interaction required by design?
Thanks in advance!!
You have to have a user authorize the application at least once. This is just the nature of the OAuth implementation and you can't work around it. Having users go through the OAuth flow is considered a best practice.
If you have an OAuth token for a verified admin of Yammer, you can use impersonation to get tokens for end users without them interacting with the OAuth flow.
The below from Microsoft blogs might help you & added source at the end of answer.
Obtain a Verified Admin token for your application in one of the following 2 ways
a. Create the app with a Verified Admin account and then in the app’s Basic Info page, click “Generate a developer token for this application.” Note that you’ll need to use this app’s info in the JS SDK and any subsequent calls.
b. Use the process outlined at https://developer.yammer.com/docs/test-token with a Verified Admin account to get an OAuth token for that VA account. Note that you must use the app info used to generate this token in all future steps.
Obtain the current user’s email address in the server-side script.
Using the VA token obtained in step 1 to authenticate, pass the user’s email address to our Get User by Email Address endpoint documented at https://developer.yammer.com/docs/usersby_emailjsonemailuserdomaincom, and then process the response
a. If the call to the API endpoint returns a 200 OK response, first check the “state” field to make sure the user is “active” and if so, store the “id” field that’s returned and go to step 4
b. If the call returns a 404 or a state other than “active,” direct the user to finish creating and activating their account however you like.
Once you have the user’s ID, you can pass it to our Impersonation endpoint to obtain a pre-authorized OAuth token for that user. This endpoint is documented at https://developer.yammer.com/docs/impersonation and must use the VA token obtained in step 1 to authorize the call, and the consumer_key of your JS SDK app.
You now have an OAuth token for the current user. When generating the code being passed to the browser, have the client side JS SDK code first call yam.platform.getLoginStatus and if there’s no active session and you have a token from step 4, pass that token to yam.platform.setAuthToken($tokenFromStep4, optional_callback_function_if_desired(response)). If you don’t have a valid token, direct the user to finish setting up their Yammer account.
Continue making JS SDK calls as you normally would, without needing the user to authenticate.
Source: https://blogs.technet.microsoft.com/askyammer/2016/11/04/preauthorizing-the-yammer-js-sdk/
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.
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.