I have successfully followed this guide "Tutorial: Add sign-in to Microsoft to an ASP.NET web app", and introduced Azure AD logins to our old WebForms/MVC application. This is working fine in terms of logins/logouts. This is using AD rather than B2C.
https://learn.microsoft.com/en-gb/azure/active-directory/develop/tutorial-v2-asp-webapp
The problem we are now facing is our users are being logged out between 60-90 minutes - I think to do with this: "The default lifetime of an access token is variable. When issued, an access token's default lifetime is assigned a random value ranging between 60-90 minutes (75 minutes on average)"
https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#access-token-lifetime
My question is, how do I deal with this correctly?
I want users to be logged in for a period I select.
If they are active I want them to stay signed in.
I want sliding expiration turned on, and I want to be able to increase the access token to longer than 60-90 minutes.
I've seen on the Startup.cs class I can set these two properties on UseCookieAuthentication, but no cookie is created and the settings do not come into affect.
ExpireTimeSpan = TimeSpan.FromMinutes(1),
SlidingExpiration = true
Or another idea is I somehow need to refresh the token on posting the page back.
I've also seen something around caching the tokens.
Please can someone shed some light on this?
I can't find any other documentation on how to implement this correctly and users having to login to an application every 60 minutes that the use all day is proving very frustrating.
Thanks
Account linking problem for only some of our users, most users link account normally. For users linking account failed, they just see the login page refreshed to empty account name and password.
From our server log, we found for users that fail to link, the user accesses our server successfully and got OAUTH code, but after about 15 seconds, google server accessed our server to exchange the code for a token. However, the code has expired by this time.
For successfully linked users, the time between issuing the code and exchanging it for a token is about 2 seconds.
Does anybody know how to resolve the problem? Thanks.
It sounds like the expiration time for the authorization code has been set to about 10-15 seconds. While the auth code should have a short lifetime, 10 seconds is way too short. The recommended lifetime should be no more than 10 minutes, not 10 seconds.
Consider that this code needs to be sent back from your server to the user, from the user to Google, and then from Google to your server. On some networks, each step might take more than a couple of seconds, particularly since it must be done over HTTPS this adds both network and processing overhead. Each step adds just a few fractions of a second - but they can add up on some devices!
There could also be a slight clock skew between the issuing server and the processing server - likely not much, but when you have a lifetime of a just a few seconds, even a 1 second skew could be too much. If the two are very out of skew, then this could be the cause of your problem as well. Make sure the clocks on your servers are at least reasonably in sync.
The best solution would be to increase this timeout on your server when you generate or accept the code. You may have thought you were specifying 10 minutes for a configuration field that actually accepts seconds.
I used this guide to built a showcase - sign in with LinkedIn into a specific site.
Everything worked perfectly until I demonstarted it in front of a wide audience and it broke down :-( It was a great FAIL and I want to know why. Here is what I do:
1.On the sign in page the user may click a Sign in with LinkedIn button and is redirected to similar link:
https://www.linkedin.com/oauth/v2/authorization?redirect_uri=[my_callback]&client_id=[my_client_id]&response_type=code&state=[securely_random]&scope=r_basicprofile%20r_emailaddress
2.The user allows the application and is sent back to my_callback
3.In my_callback I make a POST to https://www.linkedin.com/oauth/v2/accessToken in order to obtain an access token. I use the code sent by LinkedIn, correct client ID and secret. Everything is OK, e.g the response might be:
{
"access_token": [access_token],
"expires_in": 5184000
}
4.I make authenticated requests to fetch the profile data from endpoint https://www.linkedin.com/v1/people/~:(firstName,lastName,email_address)
Headers:
x-li-format: json
Authorization: Bearer [access_token]
I started to get an error 401 occasionally, e.g.:
{
"errorCode": 0,
"message": "Unable to verify access token",
"requestId": "YX21AN6NZG",
"status": 401,
"timestamp": 1483732371224
}
It seems that some of the requests randomly passed nevertheless...
Additional details:
The user is logged in LinkedIn
The user is administrator for the LinkedIn application
I have checked the limitations (throttle limits) at in the application. Available at https://www.linkedin.com/developer/apps. Everything which can be seen is green.
I have tried all advices and hacks from this question
My app is not live
I'm puzzled!
Question: Any obvious mistake?
Question: Is there any hidden throttle limits (or security instruments) for the limitation of the number of access tokens for specific user/app combination? (I'm always using the same user and I tested pretty aggressively before the big FAIL)
UPDATE: In the next two days the Sign in started working smoothly again as described above. No 401-s anymore... :-X I've made no changes to the code base. So is this some kind of throttle limit or just LI was in a bad mood on Friday?
In case someone is curious I got an answer to my problem from LI support:
Unfortunately, we really can't assist with API issues and 3rd party apps. My guess is that there was a hiccup on Friday and you were the victim of bad timing.
I accept the explanation that I was a victim so this answers my question...
I have an access-token that worked to get data through the API, however now it has stopped working. I've carefully read LinkedIn's documentation: https://developer.linkedin.com/docs/oauth2 and have come up with why this can happen.
The docs state, that the user's session is linked with the access-token. Therefore, logging out of the session means the access-token is invalidated. This makes sense because it's exactly what I see happening.
The oauth2 expired-at is just a timestamp of the ultimate time this access-token will be valid. But it can be invalidated at any moment apparently.
Other oauth2 implementations show features for refreshing the access-token, Linkedin does not provide such feature. Therefore a user has to refresh it manually every time. Not sure if this is by design or they haven't got around to it yet. Overall their API feels pretty out-dated.
A significant number of users are getting the error message of 'GetAccessToken - Unauthorized error: Your network is not allowed to request an OAuth token for this Application' whilst trying to log in to our application.
I have checked and tested, and they are accessing the correct network with the right credentials. This is happening to almost every person, so I don't believe this to be a coincidence.
This has only begun to happen in the past 24-36 hours. Are there any suggestions as to why this error is occurring, has something changed that I may have missed?
Thanks!
Couple of possible scenarios:
It is likely that the new simplified SSO is rolling out for these
users, which means they will use their O365 credentials to login to
Yammer from now on. Every user will need to reauth external apps (I
had to for our own apps also when this change occurred for us last
week).
Tokens also can expire when user's passwords expire, so if
they have a mandatory time interval to reset this could trigger an en masse need to reauth
Make sure your JS Origins are specified in your app details if you are using the Login with Yammer button and/or the JS SDK. http://naomimoneypenny.com/2015/02/11/yammer-apps-javascript-origins-update/
There isn't clear and definitive guidance regrettably from Yammer as to why and when tokens expire. Just that they do e.g. from https://developer.yammer.com/v1.0/docs/oauth-2
Once the token expires, you will need to re-run the steps above to generate a new code and access_token.
** UPDATE **
It truly seems that Google has just screwed every single person on the planet by absolutely requiring user interaction to upload a video. Of course I know, they are free. Exactly what I warned the client years ago about, so I don't need to be reminded. Thank You.
So I would like to try to take this in a different direction and just find a loophole and a workaround to still keep doing what we are doing in spite of Google's complete lack of support or caring in any way about the developers and what they have to deal with.
It would be different if you can actually call a phone number and talk to a human being about YouTube Partner access, but you can more quickly get access to the Illuminati.
OAuth 2.0 is now the only supported authentication method period. It does require user interaction.
But what about that token? Does anybody know how long the token lasts?
If I can obtain a token just once using user interaction and place it in the database, I can automate possibly hundreds or thousands of interactions afterwards.
In other words, I'm trying to turn the user interaction into a speed bump instead of a concrete wall.
If anybody has any examples of obtaining that token, caching it, and using it afterwards, that would be a godsend to me right now.
Thanks for the comments and the help. I'm not surprised that the YouTube Developers Forum just folded and said to come here instead :)
It seems that Google has completely pulled the plug on the existing dashboard.
https://code.google.com/apis/youtube/dashboard/gwt/index.html
That link is now 404'd. Tried from several different browsers on different systems.
Registered under the new Google APIs Console already, but still get the problem.
// Set the authentication URL for this connection object
$authenticationURL= 'https://www.google.com/youtube/accounts/ClientLogin';
// Try to connect to YouTube with the channel credentials passed
try {
$httpClient =
Zend_Gdata_ClientLogin::getHttpClient(
$username = $channelfields['EMAIL_ADDRESS'],
$password = $channelfields['PASSCODE'],
$service = 'youtube',
$client = null,
$source = 'Redacted Data',
$loginToken = $channelfields['CACHED_TOKEN'],
$loginCaptcha = '',
$authenticationURL);
} catch (Zend_Gdata_App_HttpException $httpException) {
$update_error['response_body'] = $httpException->getRawResponseBody();
$update_error['error'] = 1;
} catch (Zend_Gdata_App_Exception $e) {
$update_error['message'] = $e->getMessage();
$update_error['error'] = 1;
}
This code has worked perfectly fine before, but does not work with the older API key, or the newer one generated inside the Google APIs console.
I'm attempting a simple upload and this concerns me greatly:
"The service account flow supports server-to-server interactions that do not access user information. However, the YouTube Data API does not support this flow. Since there is no way to link a Service Account to a YouTube account, attempts to authorize requests with this flow will generate a NoLinkedYouTubeAccount error."
From all reports it seems that Google has forced YouTube uploads to become interactive in all cases precluding all possibility of platforms that automatically upload generated content from working at all.
Any help or insights into the process is appreciated.
P.S - Ohhh, it's been awhile since I looked at that system and Google shut down the YouTube Developer Forums and said "YOU" were responsible for their support now :)
OAuth2 does support the ability to avoid user interaction through the offline access type parameter (ie, using access_type=offline). Check out Google documentation for details.
The solution is really rather simple. Your app needs to use oauth to request offline access. It will be given an access cide which you convert to a refresh token, which is the thing you store in your database. This doesn't expire. Well actually it sometimes does, but that's another story. Whenever you need to access the api, use the stored refresh token to request an access token which you include in each api call.
See https://developers.google.com/accounts/docs/OAuth2WebServer for details.
I don't know what you did but https://code.google.com/apis/youtube/dashboard/gwt/index.html works perfectly fine for me. Maybe it was a temporary issue. If you want no user interaction you HAVE to use YouTube API v2 OR you have to use v3 with methods that don't require authentification OR you have to provide your own youtube account credentials which is not recommended and probably not appropriate for you situation.
Several issues to respond here, I think.
1) The older API console has not been removed, but I've noticed intermittent outages to it and to the newer API console while Google is rolling out their new "cloud console."
2) ClientLogin was officially deprecated in April of 2012, not just 48 hours ago. Jeff Posnick has detailed all the changes over the months (and related ones, such as AuthSub, Youtube Direct, etc.) at his blog (apiblog.youtube.com).
3) You're right that, with v3 of the APIs, you cannot do automatic uploads across the board, as the oAuth2 flow requires user interaction. However, given the limited description of your use case, using refresh tokens is probably your best bet. If the content is user generated, somewhere they must be logging into your app, correct? (so that your app knows which credentials to leverage to do the uploads). At the point they're logging into your app, and you're starting the oAuth2 flow, you just have to hit the first oAuth endpoint and pass it the parameter access_type=offline (along with any other parameters). This will ensure that, when they grant that initial permission, you're returned a refresh token instead of an access token. With that refresh token, you can exchange it for multiple access tokens as needed (an access token lives for about an hour. I don't know how long a refresh token lives, but I've never had one expire before my own login cookies did, and then I just get a new one when my users re-login to my app).
Here's some more info on how to use the refresh token; note, too, that the various google api client libraries make it pretty smooth.
https://developers.google.com/accounts/docs/OAuth2WebServer#refresh
Also, this video tutorial from a Google Developers Live broadcast a couple of months ago might help illustrate the point: http://www.youtube.com/watch?v=hfWe1gPCnzc -- it's using the oAuth playground rather than a client library, but the concept is the same.
The answer is to use google-api-php-client, create an interactive auth page, and set up YouTube API v3 correctly with the new API console.
You can create a very simple page that will authenticate for the supplied channel and then store the correct token in your database. Is already working and uploading hundreds of videos on one channel. You do need to remember to fully activate yourself under the new API console and add the services required. Just keep authenticating and adding the services it says it needs. After that, the regular v3 upload process works just fine. On failure send a group an email and they can get a new token in 10 seconds.
Not the most elegant solution, but the documentation from Google is far from elegant anyways that Stack Overflow is now their front line support.
Just hang in there, a solution is always found. Don't give up!
I didn't get here by myself either, the other answers on this page helped me get all the way to this point. Thanks guys.
P.S - Don't forget the scopes
$client->setScopes("https://www.googleapis.com/auth/youtube https://www.googleapis.com/auth/youtube.upload");