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
Related
How can I authenticate a user with sanctum when the whole login process happens server side? The question I am asking is kind of hard to phrase so I will explain my situation.
I have a Vue SPA for my front end and a Laravel app as a backend api (they run on the same domain). Normally, to authenticate with the laravel api using sanctum, you would send the credentials in a post request, and if the login was successful, you would get the session information returned. However, I want to use steam login for authentication. I already have to whole process on the backend figured out in terms of actually logging in, however I am unsure how to pass the session data back to the SPA. Currently I have a link on my site that takes the user to the login endpoint on the api, and that endpoint will have them authenticate with steam, so the entire login process is handled on the backend. Now I just need to figure out how to send the session data back to the SPA. I guess it world be similar to using sanctum with socialite.
So far I've tried usisng Sanctums Mobile Aplication Authentication. I did this by having the user log in into the laravel app using steam, then once authenticated, a access token for their account would be created, and they would get redirected back to the Vue apps call back file, with the token as a part of the query string. Then the token would be stored and . This worked, however it presented some security issues.
The token was passed back in the url, so anyone could screenshot it and use it
Anyone who obtained the token by some other method could use it.
Here is the code for what I tried: https://gist.github.com/DriedSponge/4e8549486c2bfa33e4c0b21a539bdf85
So in summary, I want the entire login process to take place on the server, but somehow at the same time authenticate the SPA. If you have any ideas on how I can make this work, please let me know. If you have any questions just leave a comment. Thanks in advance.
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/
Using the OktaSignIn widget, I see I can get res.session.token. Can I use this (or some other attribute) in another app -- with the APIKey -- and validate that this is a valid session?
We just want a simple to use auth system and don't want to set up OpenAuth...
Can't seem to find any APIs that do what I need.. but could have missed it of course...
Edit. Basically... our front end uses the OktaSignInWidget... then we want to use this in a Bearer token our API Services layer can validate.
Thanks!
Looks like this will work...
/api/v1/sessions/me
Get id from this.
{"id":"102wtHeHhr4Q4q4rh2Fjy6pGA","userId":"00u9uwkfyfiz3Y7uk0h7",
Then... this can be passed and using the API key...Issue a GET to...
/api/v1/sessions/102wtHeHhr4Q4q4rh2Fjy6pGA
Returns...
Session...
The call to /api/v1/sessions requires the API key -- which is fine.
As you mentioned, you can use the session id to see if the session is still valid on the Okta server by:
Exchanging sessionToken for okta session
After redirecting back to your app, calling /api/v1/sessions/me to get the sessionId
Using that sessionId in the request to /api/v1/sessions/id with an apiToken to see if it's still valid
This will exist as long as the user has not logged out of Okta, but the browser state might be different - for example, the Okta session cookie will normally be deleted when the user's browser closes, while the session might still exist on the server.
Alternatively, to check if the browser session still exists, you could make the validation check on the client side by making the request to /api/v1/sessions/me - the one gotcha is to make sure that CORS is enabled for both the domains your apps are running on so they have permissions to make this request to Okta.
The above methods work, but it does sound like what you should be looking into is Okta's API Access Management (OAuth2) - it was designed for this type of flow (passing Bearer tokens to your API services layer).
Starting from the point where an user has given permissions to the app, and the access token is stored in session. Following Google's web server app example, I'm just checking whether an access token exist.
However, the token might expire, or the user might remove it manually on his account page. How do I check that the token is still valid, before executing a request?
Or maybe that approach is wrong, and the correct design includes that I should handle the error after executing the action, and if it's an authorization error then show the user a way to authorize it once again?
The latter is the recommended approach. By assuming failure and dealing with it routinely, your app is much more robust. The only downside is that an access attempt takes a bit longer because of the need to fetch a new Access Token and retry. If that's a problem (it shouldn't be normally), then you can always note the expiration time of the new Access Token and set up a background process to renew it with say 5 minutes to spare.
Trying to organize this question into something clear. We are integrating Google for Work into our application, to use login, Google+, and eventually Contacts, Calendar, etc. As is recommended by Google and everything I have read, we are going to use incremental access, only adding scopes when they are needed. We are a PHP shop.
But, we will also be needing offline access, as our Contacts (and eventually Calendar) access will be synchronizing with our internal database.
We currently capture the Access and Refresh Tokens when doing the initial link, and store them locally, so that we can re-authorize at any time by using the Refresh token whenever the Access token expires. This is working correctly.
Questions:
a) when adding the incremental scopes for Contacts, the documentation says we need to call the gapi.auth.signIn() function in the page javascript with the new scopes. This is working on the page where we are allowing folks to manage settings. In the original login function callback, I save the Access Token and scopes with an Ajax call that uses the access code passed into the callback, and calls the Google_Client authenticate() function to get the access code and scopes... but at that point, the information I get back does not have the new scopes. Why? Do I have to re-extend the scopes every time the page is drawn?
b) since we are going to have a batch process do the contact synchronization, do I need to get an entirely different access token with access_type=offline, or can I use the current access token (properly extended with the new scopes). Can an off-line access token be used for on-line access as well as off-line? Or vice-versa?
For your questions:
a) have you used the parameter "include_granted_scopes"? as mentioned here:
https://developers.google.com/accounts/docs/OAuth2WebServer#incrementalAuth
b) When you request an offline access token, the response contains the access token and refresh token. so you can refresh the access token after it expires without having the user grant the permissions again.
online access token and offline access token work for the same.
the difference between both its the capability to refresh the access token when it expires without involving the user. Which is the functionality for the offline type.
The online access token doesn't mean that it works for your client-side authentication (done in the browser) and the offline works for the server-side.
You mentioned that you can get an access token, refresh token and authorization code from the client-side of your app. You could send that information to your server and make api calls from there, although this is not a good practice.
I would suggest that you do the OAuth Flow in the server side and from there manage the users information and API calls.
Here you can find the documentation on both Web server applications and Client Side applications.
Hope it's clearer.