I have two example of oauth2 clients in php, one works and the other not, it return an error instead:
([error] => unauthorized [error_description] => An Authentication object was not found in the SecurityContext).
My question is, when it should a oauth2 server returns an access token response with client_id and when should it return a response with refresh_token?
My working request is:
string(130) "{"access_token":"b91f15ed-436f-470d-8d9e-bf245c5373ae","token_type":"bearer","expires_in":25209,"scope":"read","client_id":"tonr"}"
My not working request is:
string(126) "{"access_token": "eaa3c66ae1", "token_type": "bearer", "expires_in": 31536000, "refresh_token": "69f9c2cb29", "scope": "user"}"
Since it just changes client_id and refresh_token, when should it come one and when should it come another?
The refresh tokens are managed by the third party app you are using to get the access_token. That been said you can't directly request a refresh token.
Related
I am trying to decode the access token at the backend which i receive from frontend using okta jwt verifier. I am not sure about which type of token i am getting as it does not seems to be JWT token.Login module has developed by some other company and client is not aware about the Encoded mechanism.So the access token we are getting is of the form:
The entire response that i am receiving at login -
success({
"scope": "userinfo offline_access",
"token_type": "Bearer",
"expires_in": 3600,
"access_token": "CfDJ8G7oFS712aJJkUnWhDsiXlVRL4XtxRzsNbl6up_LvGbZlZtW1RwE9pRxsVC73MT6I-r7Wvj7rVsb-jp6hghJYrHLrk9KqEmUDOtHDhE63edAGnPm3WntjEL_dQyanOXHb7aiSWFeLDVak_tV0lH6DSMCbpvy-6Cr5TPmCBHRUZybOQWYl36aidrskEvZACuPy3AvfkSCnIcFIjDuh7JSk7IU_LPZzI42Pa-O2-6V4LGf6pqtdLmO1KZIPD6gtOJn7Fidk_SDOxW74OuPakBLCf_7kQAwV1qB8lyG_Dcz_fL5qK45T9iqtyf_nB6rtwvdj07rzqgGGQ6T_JAUOAo745xoF7gnl-hIZ8pxu9OPgGdC8ymFqSneFuOhv2QZty6OMVc_ORlqoW3XTtntmBuEBSYUKnYmb4n-JAkg_cAvj-lvugxBrlHJqFKUabPbZC6_MWsMabonq0IAI_-CP7OcFcjRXGgyqgTtyYYU8UfbsYhJtp7eYyQSd_WNebiEuYOQoqrCigY7XzHoCV97YQ1TuotpuLFtHDzXc1gi_1DAozrira2LCh2DOrbAsmucKwun-G5pi2VbjFwTLknbz9vcfgrfxhq6AD9P1SALG2UtPgBMoMJ0ZW4VyEJ83NCAqaOrhHMuNrPEwdB3vrEqydJerH0xbL3Z8NtE54qu_vN6IGt8yO1SkQFNibui3FBG8Aq26zsjMusC9AlXX1EMqyLK5w9VzdbzEbeY7T5od9gYqMUR_5N1Xpr8vNKuMAanqNBHqkHBsOTgumSluSoa4BKHPS4eSvImo8ip2siKRkk3c348XqR_kIGToyuElROpVZuZ1PfTTp0tYpneCfKIHwtymt11gq-vZ-3dPjOSGQU-W5zemFAyhrEv-6NSQfGI-vi4rsWPr6fpeGgiEA3CkBUanbrXbsM3-48cHFkj0NkG3z1bTGqoAHmwP9Fub8-EhQDpNd74znYyi75Un_OjbLb2pvZ8Vp6ewRClaCEjXL44_7SOWyQ-uNnjIS_wlJ01WzRj6Nj9VNTlhYktBhi0LbUIYiaRrazCF671pc3KxYmLQzh8tLw-x-pG5UHLQNnId6YgbNL9vXi8B7NaKOMMI7ip46mO32rSxS4TE2cWjxUFeDMoRxN3XaZ9TLANvrvDpdZVSRyTpqHVmjk5Lfnj8GAUG4FY9NWYHsGLwXnT3Nn2GAgKjjVRTpUoSuXrqDCzM0fXDRAFPZ8SLe5YviG6_O4AtqGGzqj7wUUcotkwrH4WU7xVcDBip4L8yEudNCPpQkLOs0tdU5qysO8pAyVgJ89taBWeCB3VkKTdi9VXgOpUjg_wJU2eAez_xVkf3qgovk80vivhIrjRVAh0vyPVmYWwF1uwsjzx_w3_3HYspbPIC7KSpmxaMdiTg6a2wJtimdo_wmhNIJhe-EY60VG0Hlnmv6kuiakXqhyuFLl-XC97TrZL",
"refresh_token": "CfDJ8G7oFS712aJJkUnWhDsiXlUEOo0WAwIjVHVFeMiNBX4jl9mIJhwKW2uzS4OaiwhddF9LBbKOWkGaKw8vNynImRV0wJmHpp8U6iWP3UIY29s6rD65_iwrsPYfiBnrGUfusTCPRLG43Px1VQIgsBGhSGkys8t89IlKFLn7ec48Hkj8SKE0gAU6MhncTCZcyuuPzy-ip_u7OSwfxVd495qcpsnTbcxU2kfITyoVOl25NBXKYdaemMoqznEN4DMgfXNStNNTXgl0P6W6ag7frCVaiQSd9vHS9wohmLVmGH6-jyZ7Fad7LRIKMZgtMCONssGE2b8Bi0FhCJsKwYelFRcfR2Ox4IRBz0yTe8bQ3qfgYxcO4DzP9IT6kg0gZODNIi-CfhtOufMGUS5ZW6jTKXz5JFjF7JpwlY3vZokIWtu-HWrLsrFYUBGvBFxE6vWMuJ9GKv1B8Av85BKilWe3t8ND24-zDj0LIl7eZGmVa596VhoB7uepL4rQQb22f4Qagcw3NwUUfwl9Y4F-nguYZZxFNeESJItJ5Zlk6QUMaOQytMqCbxIB1ZuO_9-1qpo4EFv5rvFUPyMsU6o0Z78jytUVipgWu91Uzy0EDa6Qq9HgmYKykocxpMgerfKWo4W1z1qiCdjQ5g5n-Vzv50ZfD18HiCk1F3viiUEvMFUE3JmXVJ_YVoO0170LFryhSpTCsgx-UxiePKRXmhTheeOGxMNbhYCI6TXhgknesYFibdbds-3oLe135B0RJ3wG3_-NuEVLARWsPabYwF8puHIpHMH6io0oC4TcerOL-HfyI0CfvxNMRHydGQhVwSk72ja7yi0I_1BnnKop2UMtt_xGfkUkUlNXfJkvXAigUC77IphlfnMoQ5WZMWj-sPyHR-180z4OkeS8vXAwGxDFYI2Cl0Dc1XQXsbxQq98zxFWh7oni4EUxeb5eLoiK_zTcmQsq-4uq_W-PRGRS-QlkiHWKMvNykMWhYBSxpzHORfG4RRE4fVbdWbHMU0gh2d74mbXCJanw-ViYXdO2u3zh-k8oMbmHp2nNw3SBsMcCZPE2pOkdNlxGJTF1B9pS9BfTlxc60uF7JC9u57UqjGa-bA_xVOnvdB72JtVjtpV4eU9OWczfkCNlnWt7q4QBskVpI7zMuQfFhWaa4lbilrKuUwl1O057qvcP2cm800qeT3FGgebIXnfFmUEXCA4K28nvPa50yHXxK8nS6iKsPZSKSXaDenyCLjejxd4IyrYj0B02GXJLq7SmpZVYaQRoUq8AAawI0OUxoD31jj_bR_IdComt1Fljiz0y8BZxH74_sYl0gNTV1o6tDOEbE_2BeX7fiTJtMOk33W5kqeqsHA9stPUk8rZyOLSoK3u1tLAr0wZfnWSMw6GXu1gtG8UKuYD5SkqtnjPSOKZkvgS2D_aLKaBdNPqwoWSlqsLETiu2XbnDrunaSpRyIddYnHG9_r9zfSzXHYVEIjkJc9ix_V3tFjDOHkhi6Jg1qtYyG3l-BWGODo0uyduYKDoVJ9hjHdAlFy7gp87iE_LW-LN56IcziAFfPyV5cqYyQ571UFFET4kVTK3ypRrkEgPwwaGvj8Mm0IptJDpXOD6_wJm92YGgwlkGFsly1girz9YcOZpXfzo7KU1-s_zxSPLSx15eRvKU8FRblcSZZI1oGR8x3h1Cw-3dS3PkPkeidTVwN9In_VDWx4RgR6uwt6yxQJ49ZMKufvnv2DaZVr2pzSuj9a4BtNw7c_sIohE-Or8GbaksncXfD_JGMXR28NsDGLaH-uLJGPdGDK0YzO3bdkqAg4RQo1QHDCLY6X11pY3jIVhsvtLZzwrR3K81-Ff_QwDPBV0D8RrMVnAKYvb4AOdBDXWrrO2BckrvAFqfA1R-BFTJUAOJC9KH18qN"
},
Optional([
AnyHashable("Pragma"): no-cache,
AnyHashable("x-amzn-remapped-connection"): keep-alive,
AnyHashable("x-cache"): Missfromcloudfront,
AnyHashable("x-amzn-remapped-content-length"): 3516,
AnyHashable("Content-Type"): application/json;charset=UTF-8,
AnyHashable("Date"): Mon,
AnyHashable("x-amz-cf-id"): o2aYOoNsMY
3jqyQfcvtCsj8qitdXuHP63Jm8A1Hg1Edo-bvJxIxq9w==,
AnyHashable("x-flg-call-id"): 88aa3619167546ca8ed0304402502fq2,
AnyHashable("x-amz-cf-pop"): BOM51-C1,
AnyHashable("x-amzn-remapped-date"): Mon, 03Feb202008: 03: 44GMT,
AnyHashable("Content-Length"): 3516,
AnyHashable("Expires"): Thu,01Jan197000: 00: 00GMT,
AnyHashable("Set-Cookie"): .AspNetCore.Identity.Application=;expires=Thu,
01Jan197000: 00: 00GMT;
path=/;samesite=lax,Identity.External=;expires=Thu,
01Jan197000: 00: 00GMT;path=/;samesite=lax,
Identity.TwoFactorUserId=;expires=Thu,
01Jan197000: 00: 00GMT;path=/;samesite=lax,
AnyHashable("x-amzn-remapped-server"): Kestrel,
AnyHashable("x-amz-apigw-id"): ,
AnyHashable("Via"): ,
AnyHashable("x-amzn-requestid"): 5c6e9360-7245-42d3-aa0c-56a6a73d286f,
AnyHashable("Cache-Control"): no-cache
]))
I am unable to find out what type of access token is it. Client has only told us that they have used Okta to encrypt the login credentials and we are unable to find out from frontend ios that what kind of mechanism have they used to encrypt the user credentials.
It does not have separated period(".") just like JWT token has.So it is something linked to open id connect and oauth using Okta. I tried searching but unable to find out such token in the URL:
https://openid.net/specs/openid-connect-core-1_0.html#RFC6750
https://developer.okta.com/blog/2018/11/13/create-and-verify-jwts-with-node
https://github.com/okta/okta-oidc-js/tree/master/packages/oidc-middleware
https://developer.okta.com/blog/2019/10/03/painless-node-authentication
Everywhere i can see JWT access token and not the above type of token. Could any one please help as i am using Okta for the first time using Node and Express.
Thank you for your concern in advance :)
For my API testing, I have been getting the Authentication Token with the help of Postman. API uses OAuth2.0 for authentication.
While using Postman, I am entering the details like Token Name, Grant Type, Access Token Url, Client ID, Client Secret, Scope, Client Authentication. Once clicked on the Request Token, Bearer token is received and is updated in the Header of the request. Please refer the image attached.Getting OAuth2.0 bearer token with Postman
But now, I want to do it with Rest Assured using Java. Hence I want to know the code how do I get the Bearer token by using Rest Assured?
Assuming you are sending the client id secret and other details in the Query Parameters, for the GET and your response header access_token has the value you are looking.
public class Sample {
String oauth_token ;
#BeforeTest
public void sampletest() {
oauth_token = RestAssured.given().auth().basic("username", "password").
.queryParams("client_id", "client_id_value")
.queryParams("client_secret", "client_secret_value")
.queryParams("grant_type", "authorization_code")
.queryParams("redirect_uri", "https://someuritoredirect")
.queryParams("otherparams", "sampleparam")
.when().get("https://uri.to.get.hostname.com/oauth2/access_token")
.then()
.statusCode(200)
.extract().header("access_token");
}
}
I'm using this example
Gmail Api
I tried to find a proper method of the api to do this and it has not been possible.
It occurred to me to save credentials in NSUserDefaults and add them to service.authorizer manually.
This works, but in about an hour I answered: The operation Could not be completed. (Invalid Credentials).
I wonder if there is a function to refresh these credentials.
Finally i find the solution.
I'm mantain the NSUserDefault Functionality
curl -d "client_id=yourClientId&client_secret=yourClientSecret&refresh_token=yourRefreshToken&grant_type=refresh_token" https://www.googleapis.com/oauth2/v3/token
The Response is something like this:
{
"access_token": "ya29.KALxxxxyvE5PI3-s6oBAP74uGFE8rOhho5XYfvExfU3lxHdX23HWbKlkR4YI1xxxx",
"token_type": "Bearer",
"expires_in": 3600,
"id_token": "xjc4ZDg3NWY5MDA5YzMzZjFlODljOGExMDFjM2UwNDMyNWQ2YmQ0MTEifQ.eyJpc3MiOiJhY2NvdW50cy5nb29nbGUuY29tIiwiYXRfaGFzaCI6InRJWVE0b2pBZfNyRlJXdFEiLCJhdWQiOiIyMDM3MjIwMDA2NzMtdGIwamF1OWhwamFsa21yaHFxcDkybnBxamo2ZjhkcWcuYXBwcy5nb29nbGV1c2VyY29udGVx1ODM5MTE5MDk0OTAzMjg3NjAiLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiYXpwIjoiMjAzNzIyMDAwNjczLXRiMGphdTlocGphbGttcmhxcXA5Mm5wcWpqNmY4ZHFnLmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwiaGQiOiJ2b3ZdwiZW1haWwiOiJqZ29uemFsZXpAdm92c29sdXRpb25zLmNvbSIsImlhdCI6MTQ0NzE2OTU5NSwiZXhwIjoxNDQ3MTczMTk1fQ.gZiYdgEPhYkQTvjgxugaMaXTIH3652_E_3h_khHgaKFA56ko3VqBF9qlzJ-1LDIoTO8G2eQWa6ncE7aEwLvxelZ8429iJUCIH-1cmeuck_LWpFIdQ9sQN8u4I7ABTRWPpZ3vL8nXMNmPGynvCDWimffYCGWeVZGs3uv0O7pFftqIKMJchVk_WyC5fm9i8m-cGPN-UcrvgZKrFEOMydvF83HQzIR-x28nB1evbMV6WN8guBdZ6pVAr_2agyzoNuSO5tkV_O-790IRmU432Omv2nHBD3QQKEqv6aHe3i_F3ioPREuWduYY3yjlg0QYyh-nrzAXyzF3wbg"
}
i replace the access_token saved in userDefault with access_token from response.
Replace Values in GTLServiceGmail service.authorizer
More information here
I have a RoR app where I am authenticating against Google using omniauth and google_oauth2 where I am requesting offline access.
How do I use my refresh token to request a current access token? Also, how can I refresh my access token when it no longer works? I don't want to have any user interface in this situation, assuming of course that the authorization hasn't been taken away.
For an example using the Ruby HTTParty gem:
Where #auth is an ActiveRecord record that stores the auth keys for the specific user you are trying to refresh tokens for.
# Refresh auth token from google_oauth2 and then requeue the job.
options = {
body: {
client_id: <YOUR GOOGLE API CLIENT ID HERE>,
client_secret: <YOUR GOOGLE API SECRET KEY HERE>,
refresh_token: #auth.refresh_token,
grant_type: 'refresh_token'
},
headers: {
'Content-Type' => 'application/x-www-form-urlencoded'
}
}
#response = HTTParty.post('https://accounts.google.com/o/oauth2/token', options)
if #response.code == 200
#auth.token = #response.parsed_response['access_token']
#auth.expires_in = DateTime.now + #response.parsed_response['expires_in'].seconds
#auth.save
else
Rails.logger.error("Unable to refresh google_oauth2 authentication token.")
Rails.logger.error("Refresh token response body: #{#response.body}")
end
I don't see anything in google_oauth2 that handles fetching a new access_token with a refresh token, so it looks like you'll need to make the exchange directly.
Google's official OAuth 2.0 documentation explains how to do this at a low level. Within your server-side code, use your favorite HTTP client to construct a request that looks like this:
POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Content-Type: application/x-www-form-urlencoded
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
refresh_token=REFRESH_TOKEN&
grant_type=refresh_token
where CLIENT_ID and CLIENT_SECRET are the same ones you used for the original authentication and REFRESH_TOKEN is the refresh token from the original authentication flow. If the exchange is successful, you'll receive a fresh access token in a response that looks something like this:
{
"access_token":"1/fFBGRNJru1FQd44AzqT3Zg",
"expires_in":3920,
"token_type":"Bearer",
}
You can follow this process to grab a new access token whenever you need one. You can either use the expires_in value to estimate when you will need a new one, or attempt a refresh whenever your API request responds with a 401 HTTP status.
I have an app that uploads Video to YouTube to a specific YouTube channel (meaning, not to any individual user's channel, but to a single channel, for which I have the Username and Password).
In the ClientLogin my server-side process provided YouTube with the U/P and everything moved ahead. However, that's being deprecated and I'm looking to upgrade to OAuth 2.0 (as per their recommendation), however, the documentation insists on there being a redirect URI, for when the user has logged in. It doesn't seem to explain how to bypass the user login (since the user has nothing to log into, or any credentials to log in *with... the app is designed to take their video and upload it to OUR channel). So, what I need is to bypass the user being asked anything, and for YouTube to simply take my channel credentials and give me back the token for me to do the upload with.
I realize that this is a totally standard and non-controversial procedure, so I *MUST be missing something obvious, but I just can't suss out what that is.
So, my question is, how do I skip the user dialog-> redirect and just provide youtube with credentials for it to accept and then upload my video in OAuth 2.0?
What I'm really after is to do follow the DirectUpload approach here:
https://developers.google.com/youtube/2.0/developers_guide_protocol#AuthSub_Authentication_Flow
And to have retrieved the user Token silently behind the scenes.
TIA
There really is no way (that I've found) to completely bypass visiting an external page to authorize the OAuth2.0 access.
The closest I have come is to create an "Installed Application" project on code.google.com/apis/console and use the device methodology.
You will receive a Client ID and Client Secret. These will be used later.
Ideally you would generate a developer key, though I don't believe this to be required at this time, through code.google.com/apis/youtube/dashboard/
I use JSON notation for headers and responses, it should be easy to adapt to your language of choice.
First make a POST request to accounts.google.com/o/oauth2/device/code with the headers
{
'Content-Type': 'application/x-www-form-urlencoded',
'Content-Length': post_data.length,
'X-GData-Key': 'key=YOUR_DEVELOPER_KEY'
}
and the data containing:
{
client_id: 'YOUR_CLIENT_ID',
scope: 'https://gdata.youtube.com'
}
where YOUR_CLIENT_ID is the client ID you obtained for the google apis project you set up earlier.
You will get a response like this:
{
"device_code" : "4/Pj8m71w5XuEMTT0ZwOJVgvlTfF4Q",
"user_code" : "5wtw67wm",
"verification_url" : "http://www.google.com/device",
"expires_in" : 1800,
"interval" : 5
}
If you don't visit www.google.com/device (defined by the "verification_url" field) within 30 minutes (1800 seconds per the "expires_in" response field), you will have to perform this first request again.
On the www.google.com/device page, you will be asked to login if you aren't already and then enter the verification code (defined by the "user_code" response field). You will be presented with a request to authorize the application and a list of permissions the app is requesting.
You want to store (at least temporarily) the value for the "device_code" field. This will be used when requesting an access token and refresh token.
Now that the permission has been granted, we can request an access/refresh token pair. This only needs to happen once provided you store the refresh token.
To request the access/refresh token pair you must make a POST request to accounts.google.com/o/oauth2/token with the headers
{
'Content-Type': 'application/x-www-form-urlencoded',
'Content-Length': post_data.length,
'X-GData-Key': 'key=YOUR_DEVELOPER_KEY'
}
and the data
{
client_id: 'YOUR_CLIENT_ID',
client_secret: 'YOUR_CLIENT_SECRET',
code: 'YOUR_DEVICE_CODE',
grant_type: 'http://oauth.net/grant_type/device/1.0'
}
The response will look like this
{
"access_token" : "YOUR_ACCESS_TOKEN",
"token_type" : "Bearer",
"expires_in" : 3600,
"refresh_token" : "YOUR_REFRESH_TOKEN"
}
This specifies that the access token expires in 3600 seconds (60 minutes) and what your current access token is and what the refresh token is.
You want to store the access token for use with your current session and the refresh token for future sessions.
When making an API request, you will want to include the access token in the Authorization header field as well as including the developer key as we have been all along.
For uploading a video, I used these headers:
{
'Authorization': 'Bearer YOUR_ACCESS_TOKEN',
'X-GData-Key': 'key=YOUR_DEVELOPER_KEY',
'Slug': 'video.mp4',
'Content-Type': 'multipart/related; boundary="f897a6d"',
'Content-Length': post_length,
'Connection': 'close'
}
You can refresh your access token at any time, not just when the old one expires. To refresh your access token, you make a POST request to accounts.google.com/o/oauth2/token with the headers
{
'Content-Type': 'application/x-www-form-urlencoded',
'Content-Length': post_data.length,
'X-GData-Key': 'key=YOUR_DEVELOPER_KEY'
}
and the data
{
client_id: 'YOUR_CLIENT_ID',
client_secret: 'YOUR_CLIENT_SECRET',
refresh_token: 'YOUR_REFRESH_TOKEN',
grant_type: 'refresh_token'
}
You will get a response like this
{
"access_token" : "YOUR_NEW_ACCESS_TOKEN",
"token_type" : "Bearer",
"expires_in" : 3600
}
where YOUR_NEW_ACCESS_TOKEN is the new token for you to use in your future requests.