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?
Related
I'm studing IdentityServer4 and I got question. I know that exist jwt token which need for checking token. It checks that token was gotten from trust server. There is access_token which need to authorize in app. How does it work? I get two tokens or jwt contains a access_token as well?
From an Auth Server(The server which issues the JWT token), you will received a JWT Token aka Access_Token. This Auth Server will contains the Secret-Key that can issues an Access-Token.
From a client(Mobile/Web/Console App), you will need to pass this Access_Token in your Request Header to your Resource Server(The server where your resources stored, normally this is your backend server) to request for Resources/Data.
(e.g : Authorization : Bearer <Access_Token>)
Upon receives a request from client,in your Resource Server, you will need to have a Validate JWT function that will validate the JWT Token based on a public-key (Security Algorithm : RSA256, HS256).
Reference:
https://medium.com/dev-bits/a-guide-for-adding-jwt-token-based-authentication-to-your-single-page-nodejs-applications-c403f7cf04f4
JWT IO Introduction
I have a resource (REST) server (written in Java/Spring) that I need to validate a Microsoft token from a client. I need to:
Check that the token is valid for my app
Get the token's email address and lookup that user in my app (I can do this)
I currently use Google, Facebook and am adding Windows auth.
For Google, I check my token at:
https://www.googleapis.com/oauth2/v3/tokeninfo?access_token={accessToken}
For Facebook, I use:
https://graph.facebook.com/debug_token?input_token={accessToken}&access_token={appId}|{appSecret}
What do I use for live?
https://apis.live.net/v5.0/????
I need something that returns my app id so I can make sure the token was created by my app.
I can get the user info from the token just fine (the URL is https://apis.live.net/v5.0/me?access_token={accessToken}) but it does not allow me to verify that the user is for my app that is registered.
What is the token validation scheme here? It's not a JWT token, because it does not have any '.' characters in it...
According to this https://developer.microsoft.com/en-us/graph/docs/concepts/auth_overview:
Access tokens issued by Azure AD are base 64 encoded JSON Web Tokens (JWT).
However, when I try to base64 decode my token, it is binary. https://apis.live.net/v5.0/me shows that it's a valid token, though.
Here is an expired token:
EwAwA61DBAAUcSSzoTJJsy+XrnQXgAKO5cj4yc8AAfD7xbB6agxt1xZJhCeONQNzKUS97NgwifhSev98+2Boa/kdgnR/hk6KzNBiFz0mNsPWQrEhTsQRbta9QyGGezyVhpYLtMbWbWHUhNh/lY3w31x/5yeuUmw/ITXwu7Qk3L8t3ESzYoy9NCJT7AzkFHf6hUgDg5lNeFbwZD5mFe3Y6NH3p3kYHDBJwDHO7VN+AlTCWc3z1n06NSxQOisOjZYZ3YrWhdaffMZ9yaBfRYcSLvBLeA8u//jfhIdunfPXQyaXnNEHp3GAlVASPcskQnRmZHIz9IcqE9ZZPpXNHcgz36UIKV1aqkDGnYIqzDsAqvmICN3tWJhrabFfPC00yUIDZgAACM68oajVfXdPAAKTFEdhizTgVDOWT7yytFJCHesQFy3yfKiJ+/lANntrgT0peCZt6cHsS1iqdF7A3WMhFc4hQP7kV29PCPTouLyNj8Ygcnl024H3usPbBqCqDrRsNNjJAdKkR2Cni9Kchw/i02NfC+DUy2LmUBTb5oHZXG7zx21K+l/HBbOUn0VRb4l+rsx7CTiabu1s3cdCrmhDDuIwWv2W8Id6Y6VBYs6zddHRY58B1YRZSQevcsT05xehrebS40E+Pyy/Z9vJXb2FTM+pY1+HvtPpxqxqn73Bp3wX1A8YH8Lbe4J/J+aHbE6mEnEvQMiavB0nrh0gTAydrBkkWuY3zbuQaQFE96/i3yWad8j0A0cU8/YquXFBo6k1oD0dWOKNOQ9x+Dad7W3yFEB2gF9jZtxU5OdV4S3uRmdqyaj2kGVI2eVrX4/13f97tKA3a2ZIF7ZUZKgpwNybOrz9COAilxZvr3Z+X1jTdTYOXWMs8tuOOpru2g64sZUzgtj0JETWJcHfg9yLC72DSaAFzDR/KRa2u+C7XGaywIPEqoUs/4iRaLc5RPtdRlLHCp0rgmIlMc0/iwR7K6N2Q5odVP7QzxlBNtGW51iHNCFgRDrQ8zNkv2hdexxt7Of2i+lqe2N3Z3ENUoQa6SRBYzFDPOka+Mr5qWVxeMeulYmXFkBh0NyKaLJIqrkSMy0C
I have a situation where i will have to download the file from the website. It is a secured site (https) and also It requires the client certificate authentication.
I have a client certificate and managed to get in. After logged in, when i tried to download the file, i am not able to download the file. In turn, the file contains the html with csrftoken. How to get this token id? In order to download the file i need this token. Could someone share what kind of authentication this, and how can i get the csrf token id using c#.
Thanks
It is not authentication. Its security to prevent cross site request forgery.
The technique is:
Any state changing operation requires a secure random token (e.g CSRF
token) to prevent against CSRF attacks.
Unique per user & per user session
Tied to a single user session
Large random value
Generated by a cryptographically secure random number generator
The CSRF token is added as a hidden field for forms or within the URL
if the state changing operation occurs via a GET
The server rejects the requested action if the CSRF token fails
validation
In your case the workflow should be near to this:
Client make a request (tipicaly a HTTP GET) to see info in their
screen.
The response HTML has a hidden field in the generated Form with
the CSRF token.
Client makes a POST when click on a button with the following data: File identification he
wants to download and the CSRF token.
Server checks that this token is valid for this POST.
Server sends the file bites to the response stream.
So, if you want to download a file programmatically with C# I think that you should do a GET first as if you were a webBrowser; retrieve the CSRF token parsing the responsed HTML and send a POST whith the file and the CSRF 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.
I just started a development of my first REST API in .NET. Since it will be stateless I will use tokens for authentication:
Basic idea (System.Security.Cryptography):
AES for encryption + HMACSHA256 for integrity
token data will consist object with properties: username, date of issuing and timeout
database will hold username, hashed password and HMAC hash
Login:
check if credentials are valid (username, compare hashed password to db value)
if true, encrypt data object
use HMAC on generated token and store it to database
return token (without HMAC) to user (cookie/string)
Request to method which requires authentication:
user sends token with each request
token is decrypted
if it is expired, error
if not expired use HMAC and compare username + generated hash with db values
if db check valid, user is authenticated
The way I see it, this approach has following pros:
even if db is comprosmised, it does not contain actual token (hash cannot be reversed...)
even if attacker has token, he cannot increase expiration by updating fields since expiration date is in the token itself
Now firstly, I wonder if this is good approach at all.
Besides that I still didn't figure out, where to store AES and SHA256 keys on server (should i just hardcode them? If I put them into web.config or use machine key than I have a problem in case of load balanced servers,...).
And lastly where do I store AES IV vectors, since Crypto.CreateEncryptor requires it for decryption? Does it mean that users have to send token + IV with each request?
I hope this makes any sense and I thank you for answers in advance.
UPDATE:
Ok, now I did some more research and came down with this solution:
token will contain originally specified data (username, date of issuing and timeout)
token is generated with encrypt-then-mac (it includes AES encrypted data, IV vector + tag of these 2 values for authentication, generated with HMACSHA265)
token tag will be written to db
user will be authenticated if:
tag is valid (token authentication)
data can be decrypted
token has not expired yet
tag matches the one written in database
user is not blocked in database (token invalidation on demand)
keys will be stored in web.config separate section. Same keys will have to be on every server (per application of course)
I didn't use FormsAuthenticationTicket because in .NET there are following issues:
same keys are used for different purposes (machinekey for view states, resources and formauthtickets)
mac-then-encrypt, used by .NET is not considered as safe as encrypt-then-mac
no built in way to invalidate token before it is expired
This is a follow up from the comment thread under the question.
You seem to be a bit confused as to what, exactly, OAuth is, so hopefully I can clarify it here.
OAuth is not a web service or something you consume. It is a protocol that describes the way that a site can authenticate a user against a service, without allowing the site to know what the user's credentials are. As a side benefit, most OAuth providers also have a web service to query the user's information, and permission to do so can be granted at the same time.
Typically, you are interested in implementing OAuth from the perspective of the site (eg, AcmeWidgets.com) so that a user can log in via Facebook or Google or something. However, you can also implement the service side (eg, where Facebook normally would be), and allow others to authenticate against YOU.
So, for example, let's say you have a web service to allow for third-party sites to provision Acme-brand Widgets for users. Your first third-party implementor is the popular MyBook.org. The flow would look something like this:
Someone invites the User to use the "Acme Widgets" app on their MyBook profile.
The user clicks on the button, which redirects to AcmeWidgets.com. The URL looks something like:
http://acmewidgets.com/oauth/user?r=http%3A%2F%2Fmybook.org%2Foauth%2Fclient&appid=12345
The user is asked if they want to allow MyBook to access their data and provision widgets.
The user clicks Yes, whereupon Acme Widgets notes that the user has allowed it.
The user is redirected back to MyBook, at a URL like this:
http://mybook.org/oauth/client?token=ABCDEFG
MyBook, on the server side, now takes that token, and places a web service call BACK to AcmeWidgets:
http://acmewidgets.com/oauth/validate?token=ABCDEFG&appid=12345&appsecret=67890
AcmeWidgets replies with the final authentication token identifying the user.
Alternately, it fails, which means the user is trying to fake a token, or they denied permission or some other failure condition.
MyBook, with the token, can now call AcmeWidgets APIs:
http://acmewidgets.com/api/provision?appid=12345&token=ABC123&type=etc
This is all known as the OAuth dance. Note that there are a number of implementation defined things here, like URLs, the means of encoding the various tokens, whether tokens can expire or be revoked, etc.
Hopefully that clears everything up for you!