I have a problem where the user still can call the API after logout the application by using POSTMAN. There is no problem with the browser side after logged out since I have removed the access token and clear the cookies. But the user still can call the API and get the results using POSTMAN, which means the back-end doesn't invalidate the OAuth token. This may cause security issues if anyone stole the access code.
I have think to apply validation before the API called. I will add a column in the database table which its' value is either login or logout to indicate the current user status. Then, I will fetch this value from database for every API called to do validation. If the value is logout, then the API will return some error message. Is it possible to do by using the spring security?
Related
I have a spring boot app where the API #Controller endpoints are secured using a token that is contained in the http header. The token needs to be extracted from the header and validated against an internal cache to make sure it is valid. If the token is valid then the request can proceed to the controller and if it is not valid then it should return a 401 to the caller.
I also have another requirement to secure some of the actuator end points. When the user tries to use the browser to access the respective actuator endpoint, it will check for a user session if no session exists then the request is redirected to the spring login page. When they login I need to extract the username and password and validate using an external service. If valid a session can be created for the user and they can then use the hawtio endpoint. The session needs to store role based information so that when the user tries to perform JMX operations it will only allow them to perform the appropriate read only / write if they have the requisite role.
Any pointers regarding how you'd try and tackle this would be most welcome. I am unsure whether this is achieved by specifying addFilterBefore or addFilter and I don't understand how having authenticated the user for the actuator I go about creating a session that can be stored in the context and checked later on for subsequent requests.
Thanks
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 am working on a website which is developed in react js and I am fetching all data through the API calls. That API calls are visible in the network section of a browser and that API call contains JWT token in the header part of all API call, So it can cause security issue due to that anyone can do that API call with the same header and same URL through other platforms like postman n all.
So my question is that how can I control that no one else is able to access it or how can I hide that API calls from the network section of the browser?
Is there any other solution to solve this security issue?
You have to assign a token to each user. The token will be given to the user upon authentication.
You have to manage access to the page based on the userId and token.
Yo should not use generic tokens for all the users.
Destroy the token upon user logout.
If the user see the token on the network they can only have access to the portion that he is suppose to have access.
This is how I do it, hope it helps.
I have an angular2 app that has a Facebook login feature. When the user authenticates themself, I then send this accessToken to the server.
The server program is with Springboot and I make use of spring social.
I want to check to see if this user is authorized. So I call:
facebook.getToken() returns the access token generated on the client side. When I call facebook.isAuthorized() it returns true...As expected, because I am sending real data.
Although if I send bogus data such as:
(The token in this case is fabricated by me) to the same API endpoint
facebook.isAuthorized returns true. This is unexpected because in this case I am fabricating an accessToken.
The spring-social dependency is this:
Why does isAuthorize return true for a real access token, as well as a fake one? How can I check to see if a user of my angular2 app has authenticated themselves through Facebook on the server side?
Implementation of isAuthorized() for FacebookTemplate can be found at https://github.com/spring-projects/spring-social/blob/a6bf2626ee8ac81765c416029ca033affc94fc6c/spring-social-core/src/main/java/org/springframework/social/oauth2/AbstractOAuth2ApiBinding.java#L87.
With this source its quite obvious that isAuthorized() only checks if there is any access token provided.
To validate your token you can run any request which need authorization (e.g. userOperations().getUserPermissions()) and check for InvalidAuthorizationException or you can find some inspirations in how to verify facebook access token?.
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).