I have a work flow that works like this:
User on mobile device uses a login with Google work flow and gets a token back.
User passes id_token to my WebAPI endpoint.
WebAPI validates the token via google endpoint, saves user data to a database, and generates refresh and access tokens.
When user needs to use my api, they provide access token via bearer authentication header.
If access token has expired or is going to expired, app provides refresh token and receives a new access token.
This is a pretty standard workflow I believe. Where I am currently stuck is how to generate a secure refresh token. I'm using ASP.NET MVC 5 and would love a little direction in how to generate this refresh token. I'm actually having a hard time even finding the refresh token format as well. I can generate an access token fairly easily using the JwtSecurityToken, JwtSecurityTokenHandler and SecurityTokenDescriptor classes.
Could this be as simple as using a symmetrical encryption algorithm on a json string and sending it over the wire?
Related
I have an application developed using React in the front-end and ASP.Net Web API in the backend. I am using JWT for authorization. The process is
When a user logs in and is authenticated, 2 tokens are sent to the front-end, access token and refresh token. An access token is the JWT and a refreshes token is a random string and a refresh token is stored in a database.
For every subsequent call to APIs access token is attached in the header, I have an authentication filter that validates the access token.
Once the access token is expired, a 401 status is thrown with the error message TokenExpired.
Once the front-end receives 401, it calls the refresh token API to get the refresh token
The question I have is that I cannot have an authentication filter to validate the access token of refresh tokens API as it will throw 401 due to the expired access token, so I need to make the refresh token API to be anonymous so it does not hit authentication filter. If I make anonymous I am making a call to the database to get the refresh token stored for the user and compare it with the one I received from the front-end. So is it safe to make the refresh token API anonymous, if not what's the best way?
At Auth0, Created a set of features that mitigate the risks associated with using refresh tokens by imposing safeguards and controls on their lifecycle. Our identity platform offers refresh token rotation, which also comes with automatic reuse detection.
Please read the following topic.
Refresh Token Rotation
Refresh Token Automatic Reuse Detection
The JWT is signed using preshared secret key. Since it’s REST API in the backend and stateless, jwt is used for authorization and construct principal object
As you say, the access token represent authorisation in your application, if the refresh token is exposed then the refresh token can be presented by a bad actor to obtain an access token they can use for the same authorisation.
Using a 'preshared secret' indicates the JWT is a HMAC only variant of JWT, i.e. there is no encryption as that would indicate private and public key pair opposed to a 'preshared secret'. So the JWT is essentially a signature for the puposes of security characteristics we are ensuring integrity that the claims of the JWT are well-formed and have not been changed since signed. It also means same secret is used for signing on one end as was used to verify on the other end, the same secret has to be used because verifying a signature requires that both ends generate the signature and both of the signature match. So no data is being encrypted, so not data in the JWT is sensitive and needs to be protected.
Given this context, both the refresh and access token are a simple JWT that can only be generated by the holder of the secret - if they are exposed they can be used to make malicious requests as long as they remain valid (nbf claim).
Essentially this type of JWT can be misused if exposed to impersonate the identity the secret that signed the JWT represents, without actually knowing the secret itself, until the nbf claim expires the token - and a refresh token is the mechanism to extend the nbf claim without having the secret (which would result in a new signature, because the nbf claim would change when used).
There is one protection from access token reuse, it is the nonce claim. If you do not currently use a nonce claim you can read about how OIDC have implemented and do he same in your app. But as you say, your app is stateless but hopefully the backend has a form of state to ensure no nonce reuse and prevent JWT signature reuse. For every nonce the JWT signature changes, therefore the access token changes and can be used only 1-time. So if stolen it is a race condition who uses the token first, which greatly minimises the risk but not a perfect solution.
I have an IdentityServer4 set up to authenticate using google, and thats working great, including storing the tokens in AspNetUserTokens.
Additionally I have a separate service that needs to be able to use the access and refresh tokens to call google's API on behalf of the user later, when they are not logged in.
I'm not understanding how to request the tokens from identityserver, and keep them up to date(swap out the access token and expiration date). I can do this directly by adding an endpoint to identityserver to request the tokens, but then the external access token in IdentityServer would never be updated.
Your best bet was to use Hybrid Flow where the refresh token is stored in your service DB directly. IDS is just a proxy here and is not responsible for storing refresh token not issued by itself.
I'm working on implementing ASP.NET C# Single Page Application + Web API with OWIN for Twitter.
So a quick summary:
The SPA client opens a popup window of the Web API that, via the OAuth/Owin-Twitter middleware, redirects the user to Twitter where he enters his username and password. Via back and forth of requests and responses, the Web API receives an authenticated access token from Twitter. The only reliable piece of data I have at this point is the access token.
So the question is:
Is there a way to verify an access token, that it was issued for such user and for such app/consumer?
After days of research, the only thing I have seen so far is:
GET account/verify_credentials
https://dev.twitter.com/rest/reference/get/account/verify_credentials
But thing is it requires a user context. I need a way that is workable with just an access token.
Any help would be greatly appreciated.
I'm using OAuth2 that comes with MVC4 templates by default.
I use Facebook and Google+ authentication today and collect aditional info from them using the access token provided from the Standard OAuthWebSecurity.
Now I'm adding Linked In. When a user connects with Linked In I call different methods (under ExternalloginCallback Method in the Account Controller) depending on the provider.
The LinkedinClient returns the object DotNetOpenAuth.AspNet.AuthenticationResult with extra-data: accesstoken, name, headline and industry.
When I use the accesstoken to get more information about the user, LinkedIn returns "invalid accesstoken".
The accesstoken that is returned turnes out to be the Linked In Oauth User Token, and not the user specific token that I need to have to access more information about the loged in user.
Is there a way without writing a custom Oauth Client to retreive the correct token or does the Client make a call that does not receive the correct token?
So typically when I finally posted my question I found this Custom OAuth client in MVC4 / DotNetOpenAuth - missing access token secret answer which will solve my problem and it seems it would not be possible to intercept the other token in another way.
I'm using C# to build some functionality for a website. They want to twitter a message to their account at the point when a new vacancy gets added to their website. I face the issue that when i try to do this using the OAuth token approach i have to grant access to the application everytime. I want this all to work automatically without the need for permission. Can i login the user and then just post a message or how do I approach this?
With OAuth you only need to get their permission once, and you can save the Access Token that Twitter returns to you and use it to act on behalf of the user as long as the user does not deny you permission to act on their behalf or the token hasn't expire. Twitter does not currently ever expire tokens see Twitter OAuth FAQ.
Just save the token along side the username in the database and use it to send post requests whenever you need to post to twitter.
Twitter puts it this way in this Transitioning from Basic Auth to OAuth Guide:
Prepare long-term storage for access tokens and secrets
Whatever your storage system may be, you'll need to begin storing an oauth_token and oauth_token_secret (collectively, an "access token") for each user of your application. The oauth_token_secret should be stored securely. Remember, you'll be accessing these values for every authenticated request your application makes to the Twitter API, so store them in a way that will scale to your user base. When you're using OAuth, you should no longer be storing passwords for any of your users.