I have an MVC4 web application that uses LinqToTwitter to display Tweets when a user's profile page is visited, if they have a Twitter handle.
For this I use ApplicationOnlyAuthorizer:
var auth = new ApplicationOnlyAuthorizer
{
Credentials = new InMemoryCredentials
{
ConsumerKey = "twitterConsumerKey",
ConsumerSecret = "twitterConsumerSecret"
}
};
auth.Authorize();
My problem is that I have found that auth.IsAuthorized always returns false, even when I have call Authorize() and am successfully able to make calls to Twitter. And also, I have found that if I call Authorize() in every call made to Twitter, that an unhandled exception is thrown if I repeat the call enough times.
It seems quite important that I am able to know if auth is authorized before I make the call to Twitter. For now, I have put in a quick fix where I store my own IsAuthorized Session variable - but am not sure how reliable this is, because the Session variable could outlive the actual authentication itself?
Any advice on this would be appreciated.
The first time you authorize, Twitter will return a bearer token. After Authorize, you can grab this from the auth.BearerToken property. On subsequent calls, you can re-use the same bearer token. The bearer token doesn't expire, unless you invalidate it. Twitter's recommendation is that you use the bearer token for about 15 minutes and then re-authorize after that.
Related
I have an odd problem. I'm new to JWT authentication so it's probably something I'm doing wrong.
I'm testing out the Refresh Token mechanism and it works sometimes but not others because sometimes the JwtBearerEvents.OnAuthenticationFailed event does not fire.
I'm using C# (.NET 7) to build an ASPNET Core WebAPI.
Essentially:
On log in (via an AJAX call) I create a JWT token (expires after 10 seconds) and a refresh token (expires after 10 days) and send each back to the client in a cookie.
Chrome correctly lists both the JWT token and the Refresh Token cookies.
I make further (valid) GET requests via AJAX to the API methods which process and return successfully.
If I make a request just after (but within a second of) the expiry time of the JWT token then the JWT cookie is sent to the API, fails validation and the OnAuthenticationFailed event fires.
The Refresh Token mechanism does its thing and the JWT token and Refresh Token are successfully refreshed. Chrome shows the updated cookies correctly. All brilliant so far.
I make further (valid) GET requests via AJAX to the API methods which process and return successfully.
But...if I make a request a bit longer after the expiry time of the JWT token (only a second or 2 difference to Step 4.) then the JWT cookie is deleted by Chrome and is not sent, so the token validation never occurs, the OnAuthenticationFailed event DOES NOT fire and the Refresh Token process is never called.
User has to log in again because the Refresh Token mechanism didn't happen.
I guess my question is: Is OnAuthenticationFailed the best way to determine if the JWT token has expired, or is there a more reliable way? I've looked online but can't find any resources to explain this.
Is OnAuthenticationFailed the best way to determine if the JWT token
has expired, or is there a more reliable way?
I think you'd better judge from the expiretime,and there's a claim typed of exp indicates the seconds from 1970-1-1 to your token exp time
after you authoried succeeded，you could try to get the claim type of"exp" from httpcontext
app.Use(async(context,next)=>
{
var claims = context.User?.Claims;
var exp = claims.FirstOrDefault(x => x.Type == "exp");
await next.Invoke();
});
Or you could try to check the claim when you validate the token
I think I've found an alternative way of refreshing the tokens which doesn't require the expired JWT cookie to be sent at all.
I'd followed a tutorial which used the JwtBearerEvents.OnAuthenticationFailed event to capture expiry and, as I'm a bit new to this, had to go through it all with a fine toothcomb to work out why it wasn't working.
The client-side code now responds to the simple 401 NotAuthorized status and that kicks of the process to refresh the token, which only requires the Refresh Token cookie to be sent.
Update: Just in case anyone else is stuck with this, in the case where the JWT cookie is removed by the browser due to expiry and therefore doesn't send it, the OnChallenge JwtBearerEvents event occurs instead of OnAuthenticationFailed.
I'm building a react native app which uses the spotify web api. I'm using the authorization code flow to authorize a user. First I get a authorization code which can be used to obtain an access token and a refresh token. Everything works!
The problem is: an access token is only valid for a limited amount of time. That's where the refresh token comes in. I understand this concept, but I'm breaking my head about how to implement this.
Let's say a users opens the app, requests an access token and uses this for some time. Then, the user closes the app. After 15 minutes, the users opens the app again. The access token has now expired, so I need to request a new access token.
I've come op with several "solutions". Can someone point me to the correct solution?
Solution 1:
Every time the user opens the app, I request a new access token and use this. Problem: when the user uses the app longer than the valid time of the access token, I won't work anymore.
Solution 2:
I use the access token that's stored in the secure storage on every request. When a request comes back with 'access token invalid' (I don't know the exact error code but you guys know what I mean), I request a new access token with the stored refresh token, and then I send the previous command again (with the new access token). But my question here is: can I use some kind of "wrapper function" which checks the response of the request, and if the response is "access token invalid", it automatically requests a new access token and runs the previous request again.
I think certainly correct solution is solution 2,and i think its clear enough.
and for using solution 2 you need somthing like wrapper function,yes its intelligently.
so you should use interceptor:
what is interceptor ?
You can intercept requests or responses before they are handled by then or catch.
in link below there is a good example of implementing refresh token in axios interceptor:
https://gist.github.com/Godofbrowser/bf118322301af3fc334437c683887c5f
I agree that Solution 2 is the best, each time you do a request you can check to see if the Access Token has expired, and if it has then you can request a new Access Token using the Refresh Token as you mentioned and then make your request, in my own project I do this in a FormatRequestHeadersAsync method which calls a CheckAndRenewTokenAsync method where I perform the following check, here shown in C#:
if(AccessToken?.Refresh != null && (AccessToken.Expiration < DateTime.UtcNow))
{
AccessToken = await GetRefreshTokenAsync(
AccessToken.Refresh,
AccessToken.TokenType,
cancellationToken);
}
You can store the Access Token and the Refresh Token and then use something similar to this before you make each request to the API this will refresh your token and then you can store the new Access Token and the existing Refresh Token.
I am currently implementing a feature that you have the ability to save a song displayed on my iOS application (written with Swift) and this save button allows the song to be appended to the user's Spotify library. According to the Spotify Developer guide, the only scope required for this feature is user-library-modify when authorizing the app with the user. The url to be opened goes like this:
https://accounts.spotify.com/authorize/?client_id=my_client_id&response_type=code&scope=user-library-modify&redirect_uri=http://my_redirect_uri
This all works perfectly - the url is opened for the user to approve of the changes my app can make and the callback url with the required code is in the url is opened.
The next step in performing the required function is to get an exact token in order to use the api, which is done by calling the url:
https://accounts.spotify.com/api/token?grant_type=client_credentials&client_id=my_client_id&client_secret=my_client_secret&response_type=code&redirect_uri=http://my_redirect_uri&code=the_code_I_just_retrieved
With this url, a json file is returned with the new token and info with it, BUT when looking at the permitted scopes the token has, it is empty:
["scope": , "token_type": Bearer, "access_token": the_token_string, "expires_in": 3600]
Also, when I still try to perform the request it returns:
["error": {
message = "Insufficient client scope";
status = 403;
}]
In this lengthy process, what am I doing wrong? In case you are wondering, here are a few things I have tried without success:
1) Re-listing the scopes in the explicit token request
2)Adding utf-8 encoding to the redirect uri (not sure if this changes anything)
3)Adding many other scopes (although this clearly does not target the problem)
If anyone knows what I am doing wrong or has any suggestions as to what I should try, I am grateful for any helpful response!
I have found my mistake. The grant_type I have entered in my url set to client_credentials. However, this method of accessing the web API only permits the usage of publicly available data, not user info. Therefore, this method of authorization does not accept the parameter scope, forcing the spotify account service to ingnore this additional parameter. The other options DO allow accessing the user data, which are:
authorization_code, and refresh_token
The way this now has to be done is to:
1) Authorize the user regularly (with supplying the scopes) to retrieve the initial authorization code
2) Then, with this code, make the token request, but specifying the grant_type to be set as authorization_code
3) You have then received a valid access_token valid for one hour AND a refresh_token
4) Use the access_token when necessary and when this token expires, make another token request, but this time with the grant_type set as refresh_token and setting the code parameter to the previously gained refresh_token
5) You now have the next access_token and refresh_token
6) Repeat steps 4-5 until infinity
I'm using the Instagram API and want to get the access_token in order to throw api requests over my own account. When I try to follow the first step and get the authorization code programmatically using RestTemplate I can't get it work.
String AUTHORIZE_URL = "https://api.instagram.com/oauth/authorize/?client_id=<CLIENT_ID>&redirect_uri=<REDIRECT_URI>&response_type=code";
String url = String.format(AUTHORIZE_URL, clientId, redirectUri);
String o = restTemplate.getForObject(url, String.class);
The response is the html code of the login page because Instagram requires the user to be logged in to check if the app is authorized (of course it is, since the app an the user belongs to my own account).
How can I authenticate before throwing that request so they return the code to my redirectUri and not complain about login?
Note: I tried simulating the request to their login form but it returned a 403 Forbidden.
NOTE: I already got a valid access_token, manually generated, and it works perfectly but I want to implement also a process to re-generate a new access_token automatically since they may invalidate it at any time in the future.
Even though our access tokens do not specify an expiration time, your app should handle the case that either the user revokes access, or Instagram expires the token after some period of time. If the token is no longer valid, API responses will contain an “error_type=OAuthAccessTokenError”. In this case you will need to re-authenticate the user to obtain a new valid token.
In other words: do not assume your access_token is valid forever.
Instagram is upgrading their APIs and the flows. Earlier we needed access token to bypass forced login screen. Since yesterday, they have removed that.
Now if you call this code, it will check if you are already logged in or not. If so, it will call the AUTHORIZE_URL of yours and will send a response code. The format will be either:
On success validation - http://your-redirect-uri?code=CODE
On error - http://your-redirect-uri?error=access_denied&error_reason=user_denied&error_description=The+user+denied+your+request
Now what I'm doing is I'm directly calling the above URL of yours every time. Now if the user is logged in, a response code will be sent to you, else user will be asked to login and validate your app and then the code will be sent. Technically, you are eliminating the possibility of the error case! So no need of overhead of storing access token in your database or verifying its validity.
Just try and check now what happens.
PS: If you want to check API behavior, simply type the URL on the browser and check what it returns! It helped me a lot while coding and debugging! :)
Long story short. I have a login form in the header on every single page, when I log in successfully it works fine but when the user is incorrect for example it redirects to the default login page (a view that was originally created with MVC project) with the model errors. I don't want to do that, I want to show errors next to the login form without redirecting. So I decided to implement a login via WEB API - i.e. it does $.ajax jQuery request to the Login API Controller, tries to log user in and returns errors if needed so I can output them where I want.
All examples I've seen say to use Bearer Access Token. I don't understand why would I need to go this path - save the token somewhere and pass it along with every single request in the headers? That's what I did in my Login API Controller:
var user = await UserManager.FindAsync(model.UserName, model.Password);
if (user != null)
{
Authentication.SignOut(DefaultAuthenticationTypes.ExternalCookie);
var identity = await UserManager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie);
Authentication.SignIn(new AuthenticationProperties() { IsPersistent = false }, identity);
}
else
{
error = "Invalid username or password.";
}
This is the same functionality that is available out of the box when you create MVC5 project. I just moved it from regular controller to API controller. And it works without needing to take care of some bearer access tokens. What's the point of it if you could just do it like I did? I think it just makes requests more complicated when you use bearer token. Am I missing anything?
As I understand this, the bearer token would make more sense when you need to have a separately available backend authenticated with the same login as the front end we site in a pass through so the back end can "see" the request as coming from the same user.
You can verify that after logging in this way both the front end web site and backend api are sending the same session cookie, and if so you are golden. If on different domains, you may have problems with that, but otherwise not. If so, then a bearer token to pass that user to the backend may come back into play.