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
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 have a code that authenticate using Azure AD
I'm using openIdConnect Lib to authenticate with azure AD.
The scenario as below:
user open the URL of the app.
the app redirect user to Azure AD to authenticate
get the id token & access token
then AzureActiveDirectoryAuthMiddleware get the context and continue the scenario
this scenario is happenning from the UI, i need to know if i need to pass step number 3 (id token & access token) from postman and the middleware will continue the flow, how i can do this flow?
because my app will be used from UI and from postman
Using c# owin
if you want to check/test the middleware(some REST endpoint) functionality using the tokens through Postman, then copy the AccessToken and open Postman, set the Authorization type as Bearer and add the AccessToken as BearerToken and test the REST call.
Please make sure that the token added should start with Bearer (example - Bearer xyzabc)
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 been securing a webapi using Rob Sander's instructions, found here: Securing a web api with adfs 3.0 and jwt tokens
I have successfully performed a login via ADFS using the usernamemixed end point, and have received the encoded Json Web Token (JWT). That's fine, and I can successfully validate the token with the X509 certificate found in the federation data xml found on the ADFS server.
I have implemented a DelegatingHandler so that any Authorize attributes added to methods will be checked.
The final piece of the puzzle is where I can get the refresh_token from. It would make sense to come from an ADFS endpoint, and I thought it would be in the response from the usernamemixed end point, but it doesn't appear to be there. Also, how do I make a call to request a new access_token if I provide a refresh_token?
Normally, there's another OAuth endpoint. You would have /authorize, /token and /refresh.
Not sure in ADFS 3.0 implements this?
You can get it via:
Set-AdfsRelyingPartyTrust -TargetName "RPT Name" -IssueOAuthRefreshTokensTo AllDevices
More details here.
I am using dotnetopenauth and working with google api. My problem is to get authorization code from my saved refresh token. If i can get that code then i can get accesstoken. i want to get that code not accesstoken directly. I was unable to find any method or url of end point which can return me authorization code from my refresh token. Thanx in advance
I think you have the OAuth 2 flow confused. Authorization codes do not come from refresh tokens. It's the other way around: you get refresh tokens in exchange for a one-time-use of your authorization code. Access tokens are obtained in any of three ways
In exchange for a refresh token.
In the initial exchange for the authorization code that returns both a refresh token and an access token.
OR, if you're using the implicit grant type instead of the authorization code flow, you get the access token in the url #fragment in response to the user's authorization redirect, but this only applies to JavaScript executing on the browser since fragments are not sent to web servers.