I'm using the 'Sustainsys.Saml2' package for creating an SSO flow with an IDP.
The authentication cookie has no visible "Expires /Max-Age" in the browser but instead it shows 'Session'. This way i'm not sure when a user's token expires.
Our application authorizes users based on claims that are in the fedAuth token. Those claims would correspond to membership of certain AD groups. When the user gets removed from the AD group i want the application to respond as quickly as possible to invalidate the cookie or token so that the user's access would be denied.
How is the expiration of the cookie determined? Or where can i configure it? Or is there another solution that fits my needs?
Thanks in advance!
The session length is not handled by the Sustainsys.Saml2 package, but by the appropriate cookie package for the environment you are using.
Sustainsys.Saml2.HttpModule - System.IdentityModel.Services.SessionAuthenticationModule.
Sustainsys.Saml2.Mvc - System.IdentityModel.Services.SessionAuthenticationModule.
Sustainsys.Saml2.Owin - Microsoft.Owin.Security.Cookies
Sustainsys.Saml2.AspNetCore2 - Microsoft.AspNetCore.Authentication.Cookies
Related
I'm building a REST API and using AWS Cognito's user pools for authentication. I've got a "get_token" endpoint that returns the JWT access and refresh tokens to the user, which they use to authenticate access to the other REST endpoints provided by the API.
The access token has an expiration timeout. If the user of my API is an application program, what are the best practices for the application to handle when the access token expires? Does the application have to remember the username/password and re-authenticate to continue? Is using the refresh token to get a new access token and use that going forward the best approach?
Is there any documentation, suggestions anyone can point out that might help me out?
Cognito provides 3 types of tokens, id, access and refresh tokens when you login. The way this usually works is that you send either of the first two (depends on whether you want to be sending user payload information to your backend) to your backend via an Authorization header and verify the token there.
Your id and access tokens usually have a shorter expiration time compared to the refresh token. What you should do is, when the id (or access) token expire, you should use the refresh token to generate a new id (or access) token. When the refresh token expires that means that you can no longer generate new id/access tokens from it. In this case, the user (or app) must login again.
I have an auth system using JWT in my iOS app. I receive an access token from the server and use it for each request. Can I show that token to the user? Why it might be unsafe?
Whether it is safe to show the JWT to the user depends on the information in it and your organization's policy wrt. that information. If there's only information about the user in the token, it is OK in most cases. But if there's information that you want to hide from the user - which may also include information about that user that is intended for other recipients only - then no.
Basically the token is available to the user anyhow, since it is in an app on his device. He could get to it by intercepting the communication (endpoint) or inspecting the memory contents.
So if there is information you really need to hide from the user, the token issuer should encrypt the JWT.
I have a react app that uses Keycloak endpoint token_endpoint to authenticate the user. The problem I'm facing now is how to update/refresh this token. I know I could use a refresh token but that's a bad practice since has security issue when it comes to a web application. It seems to me that the best approach would be to use Silent Authentication.
Unfortunately, I couldn't find any example or documentation that allows me to achieve this. In case you guys have another approach I'm open to suggestions.
Tks
It would consist just of providing the prompt=none parameter on the authentication request as stated in the OpenID Connect 1.0 Core spec:
https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
prompt OPTIONAL.
Space delimited, case sensitive list of ASCII string
values that specifies whether the Authorization Server prompts the
End-User for reauthentication and consent. The defined values are:
none
The Authorization Server MUST NOT display any authentication or
consent user interface pages. An error is returned if an End-User is
not already authenticated or the Client does not have pre-configured
consent for the requested Claims or does not fulfill other conditions
for processing the request. The error code will typically be
login_required, interaction_required, or another code defined in
Section 3.1.2.6. This can be used as a method to check for existing
authentication and/or consent.
Authenticate to obtain an access_token with /auth (prompt=login).
Just call OIDC /token with grant_type=refresh_token to refresh token with the access_token. the new response include access_token, refresh_token and so.
After that you must update them for the new api calls.
In a very basic Token authentication the login process in nothing but providing the credentials and obtain the token. With RESTful API, the token is included in the header for any API calls to imply that the user is logged in.
My question is, what would the logout procedure look like?
Deleting the token at server-side? What if the user is going to logout from web but wanna stay logged-in in mobile app?
Deleting the token from client side? Should the server not enforcing that?
How should the server go about invalidating a token?
How are logout mechanism implemented?
I think that the logout action simply invalidate the token on the server side (delete it in your database, set a flag expired to false, ...). If you want to support several kinds of REST clients, you should be able to specify for which device you want to obtain a security token. In this case, you will be able to invalidate them separately.
To provide the device kind, you can levevage the header user-agent or provide your own header.
Perhaps this link could help you in the design of your token management: http://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/.
You talked about a Web mode. For this use case (which is a bit particular since the browser holds the token for you implicitely), I suppose that you leverage cookies. So yes, for such particular use case, the corresponding cookie must also be invalidated.
Hope it helps.
Thierry
We would like to implement "Sign-in with LinkedIn" in our app. Since the app has JS fronted and RESt-based backend, we decided to exchange JSAPI tokens for REST API OAuth tokens as described here.
If a user successfully signs in, the frontend sends credentials cookie with client-side bearer token and member ID to the backend. On the backend we check if a user with such a member ID already exists and if not, we exchange JSAPI token for REST API OAuth token, retrieve user details from LinkedIn a store it in our database.
Now the question is if we can use that cookie to authenticate each user's request to our REST backend. After a user successfully signed in via JSAPI, the cookie should be automatically passed to our backend on all subsequent requests so we can check member ID. Are there any drawbacks that we missed? Or is this idea as a whole wrong?
Should we rather authenticate a user only once by means of the cookie and then issue our own authentication token and send it back to the client?
The way cookies work in general is they are passed on every request to the domain they belong to. LinkedIn is setting a credentials cookie to your domain.
As long as you are validating those credentials on every request it's perfectly acceptable to use their tokens as authentication.
Personally I don't find that to be a great idea and would prefer to validate their credentials once and create my own auth token to use from there on out. You can always set that token to expire at some-point and re-validate the LinkedIn credentials (which will still be getting sent on every request anyway). This limits the amount of times you're checking with LinkedIn and should increase the responsiveness of your app.
Either way could work.
If you are using the LinkedIn cookie to validate a user by member id, you should validate the cookie's signature on each request per section 2 of the doc you linked and question 2 of the FAQ.
Using your own token could make it easier to implement an account which belongs to your app and is not necessarily connected to LinkedIn, assuming there's the potential to either connect solely with some other service(s) or no 3rd part(y/ies). Still should validate any time you trust the member id in the cookie though.
The doc provides a validation example in PHP, and if you're interested in improving a ruby version, I have a shameless plug.
The flow that you've outlined in your latest comment of going straight for the OAuth tokens is the best way to go if you were only signing in to convert the JSAPI tokens to OAuth tokens and then not using the JSAPI further. If you were planning to actually use both the JSAPI tokens within your front-end app and the OAuth tokens on your back-end, then it's better to take the conversion route.