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).
Related
There is a lot of good content on the internet that explains how to secure a Spring API with Keycloak: Create a Client that represents the API Service in Keycloak and use a link like the one below to get the access and refresh token:
<Domain>/auth/realms/<realm>/protocol/openid-connect/auth/{some parameters}
This yields both tokens. So far so good.
Now, however, I am not sure how the flow for the frontend accessing the API should look like.
Should the frontend directly access this endpoint and, therefore, obtain the access and refresh token? That would mean that the API can only have the access-type public because there is no way to store the client (the API) secret securely.
Or should there be a third server that somehow stores the refresh token for each user, that the user can call if his access token is no longer valid. This server would then use the client's refresh token (and the client secret that could be stored securely, since it would be in the backend) to get a new access token from Keycloak and would forward it to the user.
I guess the main question that I am asking is, whether the client/user should get the refresh token.
If one needs to implement a logic according to the second option, I would be interested in a link or description of how something like this can be done in Spring.
I think, in either case you need to use the Authorization Code Flow. The implicit flow, which was recommended for SPAs (frontends without a backend server) in former versions of OAuth2 must not be used anymore.
The best option is to have a backend server, so the user retrieves the auth code via redirection and the backend server exchanges this auth code with the access and refresh tokens (and keep them without forwarding them to the frontend).
If there is no backend in place and your frontend needs to retrieve and hold the tokens directly, I would recommend to use the Authorization Code Flow with a public client and the PKCE extension (which - put simply - ensures that the entity asking for the auth code is the same as the entity asking for the tokens and that the auth code was not stolen and used by a foreign entity). There are several sources with more detailed explanations, which might help you, for example: https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce
Hope this helps you with your architectural considerations.
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 have the following scenario that I am curious if it is possible to implement. I need to use SSO and more specifically OneLogin to authenticate the user via custom UI from my Java standalone application. I know this can be done via Create Session Login Token and then Create session via token One Login API calls. With some parsing I can get the session cookie out of the last call and store it.
Now I need to programmatically hit the API server, which is to be build still and this server somehow needs to validate the session cookie that I am going to send along with request. The key word "Programatically" as in there will be no browser
OneLogin doesn't provide SDK to validate existing session cookie => it would be nice if I could, based on session cookie find out if it is still valid and what is the user name used for this session. If session is invalid API server would return unauthorized.
Is this even possible? Or is it possible in some other way?
Basically One Login is already used in our ecosystem and I have to continue using it
The app that will log user in and get the session cookie may not be the one calling the API server. This could be another java application that would receive the session
I guess what I am looking for is Validate Session equivalent from Open ID Connect API in general API
The session_token that is returned via that API has a short expiry is only intended to be used for making the Create Session request which returns session cookies.
It sounds like OpenId Connect might be the best option for this use case. If you have user credentials then you could use the Resource Owner Password Grant flow to authenticate the user and obtain an id_token.
The id_token is a JWT containing user details can then be verified for authenticity by checking its signature, audience and expiry claims. It can also hold other custom information about the user that may be used by your backend application.
We have a web app in which we allow users to log into the app using any Open ID provider(e.g. Okta, Google, Facebook etc.). We want to implement the correct Open ID Connect prescribed methodology/workflow to keep the user logged into the site.
The existing implementation, looks at the expiry of the Access Token then if it's close to expiry uses a Refresh Token to get a new Access Token to keep the user logged in. I feel like this is wrong. When a user logs in to the web app, the Identity Token is used to Authenticate the identity of the user using the Authorization Code workflow. The Access Token and Refresh Token are stored on the server side. Periodically, the Refresh Token is used to get new Access Tokens to keep the user logged into the site. I believe this is a security risk because -
Imagine if a user is logged onto his OP account in a browser. He opens up Sky and is directly logged into MP because he’s already logged into MP. He then in a separate tab, logs out of his OP account. He will continue to be logged into MP for days on the basis of this Refresh Token/Access Token mechanism! Isn’t this a security risk?
If feel like the correct way to go about this is to use Session Management using iframes as prescribed here on OIDC -
https://openid.net/specs/openid-connect-session-1_0.html
For more context, when a user logs into our WebApp we pull data from the OP's UserInfo endpoint to create a profile within our WebApp and set permissions/roles within our app based on data sent over from the OP's UserInfo endpoint. We continue doing this periodically. For this purpose, I feel like using the Access Token(and using the Refresh Token to get new Access Token) to access the UserInfo API is correct because it conforms to the OAuth 2.0 concept of protecting/authorizing API/Resource endpoints using Access Tokens.
I want to know if this is indeed the correct way to manage how a user should be logged in when supporting Open ID Connect.
I think the first question is whether you want to bind the lifetime of an OpenID Connect provider Single Sign On session with the session of your application. You just want to authenticate a user using their OpenID Connect service. If I logout of Google, I expect to be logged out of GMail, but not a third-party application that used Google for authentication. Would you like to implement Single Sign Out as well?
But if I wanted to be logged out when you logout of the OpenID Connect provider, I would implement the OpenID Connect Session management. There is one thing good to be aware of when using iframes and cookies - browsers have an option to "Block third-party cookies" (that's how Chrome calls it), it's turned off by default, but as far as I know, it disables the SSO functionality when turned on.
I'm not sure why you request the userinfo endpoint periodically. If you just want to check whether the access token is still valid, you could also use the token introspection endpoint.
For security concerns, I would suggest you to read the OAuth 2.0 for Browser-Based Apps RFC. It recommends using the auth code flow with PKCE instead of the implicit flow. With the implicit flow, access tokens transported in redirect URLs stay in network and browser caches and can be used right away by an attacker. The auth code with PKCE needs a code_verifier (one-time secret) in order to be exchanged for tokens. So I would first check how the providers work with a configuration you choose and if it's even supported.
I am about to start working on a project, which is basically a web interface for a mobile banking application. The API is ready, I only need to provide the frontend part of the web application. I was going to make it using Backbone/Angular/Ember, but started to worry about the security.
Particularly, the following. As a rule, every API request must contain a parameter method_code, which is calculated as hash of user token, method name and secret API key. If I put the logic of how this param is calculated into one of .js files, anyone could potentially access some sensitive data using tools like Postman or even browser console. How should I go about this issue? I could have a server-side script generating the method_code for me, but is it possible to make it accessible only to my web app's requests?
every API request must contain a parameter method_code, which is calculated as hash of user token, method name and secret API key
I could have a server-side script generating the method_code for me, but is it possible to make it accessible only to my web app's requests?
Yes, the server-side script would be the way to go if you do not want to expose the secret API key within your client side code or request data.
User token can (presumably) come from the user's session cookie value? So simply have a server side method that takes the method name and then returns the method_code calculated from the secret API key (kept server side only) and the user token.
The Same Origin Policy will prevent another domain making a request to your API and retreiving the method_code. I'm also assuming the API and front-end code runs on the same domain here, although if this is not the case you can use CORS to allow your front-end code to read and retreive data client-side via the API.
You can try to generate a token based on security factors and encrypt that and use it in your requests to identify your clients and valid requests.