My WSO2 Identity Server issues a JWT, and on my .net core backend, i would like to reach out to Identity Server check the token (perhaps it was revoked for example)...
How do I do that?
Start by checking why you would do that. ANY sensible scenario for this WILL HAVE to involve caching. Which is what a token is.
What we do is this:
* You get 2 tokens, an accesToken and a refresh token.
* The access token is accepted on the backend without questions. It is valid 5 minutes.
* The refresh token is doing a full account check. Revoked? no new access token for you.
Doing exactly the same thing without checking ;)
Related
I know this topic has been discussed many times, but there are so many articles around (and answers here in SO) that I'm a bit lost.
My scenario is the following: I have a WebApi written in ASP.NET Core 6 and I want to authenticate a mobile PWA app written in VueJS, using JWT authentication.
Reading through some articles and looking at the CheatSheet recommendations here and here, this is what I have come up with:
When I try to authenticate my user in the PWA, if the user credentials match, the server generates a token which contains also a claim with a "fingerprint", a SHA256 encrypted random generated string. The same generated string is added in a dedicated cookie that is returned with the response to the client: the cookie has the HttpOnly, Secure and SameSite options enabled
Once authenticated, I store the authToken and the refreshToken in my IndexedDb. First question here: why would I need to use a sessionStorage in my case when the user will never create a different session of my PWA anyway? NOTE: my token does NOT contain any user sensitive data
Whenever I do a request from the PWA, with axios, I use the withCredentials: true option and I send to the server not only my token as a Bearer in the Authorization header, but also my fingerprint cookie
For each request received, the server unpacks the token, checks its validity (issuer, audience, signature, expiration, etc.), but also checks that the fingerprint contained in the JWT claim matches the one in the received cookie
So, from my understanding, the usage of this fingerprint guarantees that any XSS attack retrieving the token from the client storage won't be able to authenticate against my WebApi because it won't have the corresponding cookie. At the same time, the cookie is protected from XSRF attacks with the options I'm using for the cookie itself.
Is this correct? Is it strong enough?
And also: can I simplify/enhance my algorithm by using the Antiforgery token built-in mechanism provided by ASP.NET Core?
I am using the fine-uploader with an asp.net mvc backend to upload files directly to an azure blob-storage. The asp.net-server works as the azure-signature-endpoint(sas). This is all secured with an identityserver3 and here comes the problem: The identity_tokens lifetime is set to 5 minutes(as default). And I want the SAS endpoint to be only called authorized. So a user can only access its own data. But after I have the upload running for the set 5 minutes, it breaks. Of course, because it is not authorized and it returns the login-page from the identity-server(which the fine-uploader, of course, can't handle).
It would be easy to solve this problem, by either setting the lifetime from the token to something higher(but this is unreliable as the upload could take hours or days), or disable the lifetime(yeah would work. But I guess the lifetime has a reason to exist).
So my 2 ideas would be:
to just authorize the user once(when he starts the download)
or to refresh the token by code every time the signature gets generated.
First approach
Can I just set a boolean like user is authorized and if this boolean is set just skip authorization and just return the signature or how could I achieve this
Second approach
How would I do this?
Don't use the id token for API access, an instead use access token. Access tokens are for resources (APIs), whilst id_tokens are purely for authentication. The id_token is only meant to be used to provide the RP with means of knowing who the user is - hence no need for long time span. It's only there for converting into a user session (cookie/principal).
With access tokens you have several approaches for keeping a valid token at a client; either by fetching new ones using the client credentials flow or by using the refresh token approach.
I believe there are samples of both in the samples repo of IdentityServer.
Samples repo link
My question precisely is that "how is the token validating information managed on WebApi side ?"
i.e
A) Is there a unique secret key for each User?
B) If yes where are these stored ?
C) Some one said the key is generated fresh every session :O ??
I would specify how I think this is to be done or can be done.
1) App sends the username and password to login Api(Part of WebApi).
2) Api validates credentials from Database and creates a JWT.
3) A standard header is created say header = {'type':'JWT', 'alg':'HMAC'}.
4) Then claims/payload section is created and a unique identifier for that user is embedded into it.
5) Then (header.claims) is Base64URLEncoded and fed into a method which takes this encoded info and secret key as parameter and signs it using HMAC algorithm(say).
6) Now the header, claims, signature(obtained in previous step) are concatenated with periods and we get a JWT.
7) This JWT is sent back to the App.
8) During next request the App sends back this JWT to the WebApi while trying to access a resource.
9) The WebApi checks the JWT and decodes back header, claims from it.
10) The WebApi obtains the Unique user identifier from claims and checks if this user exists in the Database.
11) If user is found it gets the secret key associated with the user which is also stored in the Database against the user. (May be just a GUID generated at the time of registration)
12) It checks whether the token is expired or not. This info is available in claims/payload as 'exp' Date time or whatever.
13) Assuming that the token has not yet expired, The WebApi takes the header plus claims/payload and again generates the JWT same way it did the previous time using secret key.
14) The JWT so created is matched against the JWT sent by the App. If both match(signatures) then the token is correct and un-tempered and indeed issued by the WebApi to this user.
15) The WebApi sets the claim identity and allows the access to the resource.
Now instead of every time looking for the user identifier in the Database, The WebApi may also just maintain a static array of users as they login keeping their secret keys too. So it can just get the information from this array. As user logs out the user is removed from the static array as well.(The array management is not what I want to get into now)
This is just my way of thinking about implementing it.
I want to know how much have I deviated from the way it's done otherwise? I DO NOT want to create a separate authorization server. I want the WebApi to manage this itself in a simple but of course secure way. I will use Microsoft JwtSecurityTokenHandler for .Net 4.5 for creating, validating JWT's.
Your question is very generic in this topic and it takes many pages of answer. Please take a look on: JSON Web Token in ASP.NET Web API 2 using Owin
it will answers many of your questions
I am using jwt tokens middleware and Asp.Net.OpenIdConnect.Server in my app. In fact, it works fine. But I am confused in one thing. If I use tokens, I can not immediately grant new claims or ban my users. For example. I give my user access token, which expires through 2 days, and refresh token, which expires through 2 weeks. Then I give to this user admin rights. But he will know about this only through 2 days, when his current access token expires, and auth server will give him new token, using refresh token. How can I give him new rights immediately, on the next request?
I understand, that I need to check database for every request, and give to user new access token, if needed . But where should I do it in aspnet 5? Maybe there are some good practices for such thing?
One way doing it is to put a unique identifier into your claims, which you can query to see if it's still valid. You can use the memory cache to store it or some distributed memory cache such as Redis, so you don't have to hit the database every time.
When you ban the user or add a token, you mark this token as invalid by removing it from the cache. Each time you the user refreshes the token, it you should create a new unique id inside the token.
I'm trying to create something like: Client authenticates and gets token from custom STS1, next client authorizes with machine key and is issued token on custom STS2 and gets another token. With last token, client requests methods on RP service.
All services are hosted on IIS and are using active federation scenario.
Both STS's have endpoints with ws2007Federation and ws2007Http bindings, and RP use ws2007FederationBinding with STS2 as an issuer.
If I create channel with CreateChannelWithIssuedToken I can see only token from STS1 and can't get token from STS2.
So I decided to pass token from STS1 as ActAs RST's property on request to STS2 token. And that failed - cannot decrypt token.
How can I pass both tokens to STS2 and merge up claims in them?
Is it a bad idea - to send with RST just extracted claims from STS1 token?
Generally you will only want to utilize one token at each step. So if you need to merge up claims, you will want to do that at the claims transformation step of the second STS.
So the flow would be authenticate with STS1, then authenticate with STS2 with the token from STS1. At that point you would pass through the claims and transform to add additional claims as needed. Then the resulting Token would be ready to consume from the RP application.
I have actually started a blog series about a really similar scenario that we recently architected. Not to be overly self promoting, but it doesn't make me any money, so I'll post it in case it is helpful.
http://www.livingthearchitecture.com/mixing-sso-with-existing-technologies/
I would be glad to go more in depth, but depending on the specifics of your scenario, the specifics of the solution will change greatly. I think the above expresses the general approach you will want. Let me know if I can help any more.