I am looking for tips or tutorial where I can fetch data from youtube data api.
By using only api key, I can use any rest api client in order to fetch many informations from https://www.googleapis.com/youtube/v3/channels.
And now, I would like to get auditDetails which needs authorization token https://developers.google.com/youtube/v3/docs/channels/list#auth.
[Edit]
By following the steps below (Using OAuth guides), I can now make request but I have an error 400 which is redirect_uri_mismatch:
The redirect URI in the request, http://localhost:9874, does not match the ones authorized for the OAuth client
In my console developer configuration, I set the redirect authorized url to http://localhost/authorize.php
So I do not understand why during the authentification, it uses http://localhost:9874
Related
I am trying to get new access token from my refresh token for google drive api. In my google playground it works but when I want to create the same request in postman or my code it doesn't work and I always get error "Invalid grand type". I don't know to find what is problem.
google developers playground
postman headers and body
You need to understand that there is three steps to the Oauth2 dance.
step one is requesting access of the user and getting the authorization code.
HTTP GET https://accounts.google.com/o/oauth2/auth?client_id={clientid}.apps.googleusercontent.com&redirect_uri=urn:ietf:wg:oauth:2.0:oob&scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code
Note &response_type=code tells the server you want an authorization code returned.
step two is to exchange that code for an access token and refresh token.
POST https://accounts.google.com/o/oauth2/token
code=4/X9lG6uWd8-MMJPElWggHZRzyFKtp.QubAT_P-GEwePvB8fYmgkJzntDnaiAI&client_id={ClientId}.apps.googleusercontent.com&client_secret={ClientSecret}&redirect_uri=urn:ietf:wg:oauth:2.0:oob&grant_type=authorization_code
Note the part where it says &grant_type=authorization_code. this tells the server you are giving them an authorization code.
3 the final step is refreshing your access token.
POST https://accounts.google.com/o/oauth2/token
client_id={ClientId}.apps.googleusercontent.com&client_secret={ClientSecret}&refresh_token=1/ffYmfI0sjR54Ft9oupubLzrJhD1hZS5tWQcyAvNECCA&grant_type=refresh_token
Note &grant_type=refresh_token you are telling the server you are sending them a refresh token.
You appear to be sending a refresh token with the wrong grant type.
I have a video on how to set up postman to use google oauth2
How to set up Oauth2 in PostMan.
Google 3 Legged OAuth2 Flow
Note: Due to a recent change with Making Google OAuth interactions safer by using more secure OAuth flows redirect uri of urn:ietf:wg:oauth:2.0:oob is going to stop working soon.
I want to get an API token for a specific user using openshift rest api. I have a web application which can be used by any user in my organization. I want to be able to authenticate the user in my application using an internal oauth service, after authentication, i want to authorize the user to be able to call openshift rest apis.
I have found 2 APIs, /authorize and /token which get called up to generate api tokens which can be sent as Bearer 'Token' in the REST APIs headers. But not able to find a way to call them. I have been facing CORS errors calling these APIs using AJAX request.
https://openshift-master.bruxelles.sodigital.io/oauth/authorize?client_id=openshift-browser-client&response_type=code
This url is internal to my organisation which authenticates the employees if not authenticated, and then displays a token on the web page. I want to be able to get that token.
I'm writing an API back-end that I want to use OpenID Connect (OIDC) to secure. I've been reading the documentation but I'm still a bit confused what process applies to each and every API request. The Open ID Connect code flow appears to be:
Which I'm fine with, as a one-time process. My back-end API sees an authorization code in the HTTP headers, and sends a request to the authorization server to get the id token. Assuming this validates OK, the data requested is returned in the API response.
But assuming the same user will then be making lots of requests to this API, what happens in subsequent requests? Is there some sort of session created in this mechanism? Do I continue to receive the same authorization code? Do I have to keep sending these back channel requests to the authorization server?
Or should I even output the JWT id token as a cookie? In this way I get the self contained id token coming back in future requests, with no need of a server side session, or further round trips.
I've been reading the documentation but I'm still a bit confused what
process applies to each and every API request
It is not the API that should follow OpenID connect protocol. It's the client that should do it.
My back-end API sees an authorization code in the HTTP headers, and
sends a request to the authorization server to get the id token.
Assuming this validates OK, the data requested is returned in the API
response.
Authorization code must be used by client application and not by the API endpoint. Also, authorization code must never be exposed to other entities.
You should use id token sent with OpenID Connect to authenticate the end user from your client application. To access API, you should use access tokens.
What to do in API endpoint ?
I think this is where you struggle. Your client application should send a valid access token to get access to API endpoint. From API endpoint, you can use OAuth 2.0 introspection endpoint to validate the tokens.
RFC7662 - OAuth 2.0 Token Introspection
This specification defines a protocol that allows authorized
protected resources to query the authorization server to determine
the set of metadata for a given token that was presented to them by
an OAuth 2.0 client.
Note that, OpenID Connect is built on top of OAuth 2.0. This means you can use anything defined in OAuth 2.0, including introspection endpoint. Use this endpoint to verify the access token validity.
What if you want end user details ?
OpenID Connect defines a user info endpoint
User info endpoint
The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated End-User. To obtain the requested Claims about the End-User, the Client makes a request to the UserInfo Endpoint using an Access Token obtained through OpenID Connect Authentication. These Claims are normally represented by a JSON object that contains a collection of name and value pairs for the Claims.
Here also, you use access tokens to get user information from this endpoint. The response will let you know the end user to which this token was issued.
Depending on your specific API requirement, you can do a token introspection or obtain user information from user info endpoint. Once that is done you may go ahead and authenticate a session. You might use both endpoints if you need all available information.
Alternatively(instead of sessions) your API can maintain an access token cache. This will remove the need to validate tokens in each an every API call. But be aware that tokens have expiration time. You must consider about token expiration if you are choosing this solution.
p.s - Client vs Resource server
In OpenID Connect and OAuth 2.0 terms, a client could be a simple web page, desktop application or could be even server hosted application.
client
An application making protected resource requests on behalf of the
resource owner and with its authorization. The term "client" does
not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other
devices).
Obtaining tokens and using them is the duty of the client application.
On the other hand, resource server contains protected resources,
resource server
The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens.
Resource server exchange it's resources to access tokens. If we match the same scenario to basic authentication, access tokens replaces username/password sent with authentication headers.
Typically you'd secure a (pure) API with OAuth 2.0, not OpenID Connect. The Client accessing your API should obtain an OAuth 2.0 access token and in order to do that it may choose to use OpenID Connect to obtain that token. That is all independent of the API, which will only see the access token. The API (or Resource Server in OAuth 2.0 terminology) is not depicted in your diagram.
Im writing a application for outlook, front-end Angular, backend Web API.
I'm successfully getting access-token using adal in front-end, sessionStorage is:
adal.access.token.keyxxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09:"Access-token"
adal.error:""
adal.error.description:""
adal.expiration.key:"0"
adal.expiration.keyxxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09:"1482073764"
adal.idtoken:"access-token"
adal.login.error:""
adal.login.request:"http://localhost:8080/"
adal.nonce.idtoken:"xxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09"
adal.session.state:"86xxxxxd-xxxx-480b-xxxx-34923xxxx918"
adal.state.login:"9axxxxxx-xxxx-xxxx-xxxx-360xxxxxx94"
adal.token.keys:"xxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09|"
adal.token.renew.statusxxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09:"Completed"
Now i'm sending access-token to backend, and i want to get messages from outlook API, but how can i do it.
Searched for outlook REST api, and tested using POSTMAN, but not working.(401 error)
Get https://outlook.office.com/api/v2.0/me/messages
Authorization: Bearer access-token
Accept: application/json
Any suggestions on how to do this?
Thanks in advance.
It looks like you are trying to complete the on-behalf-of flow.
This is where a front-end API gets an access token to a middle tier service, which subsequently gets an access token to a back-end API. Let's assume that the token from the front-end to the middle tier has user context. You are able to get a token from the middle tier, to the back-end using the same user context, by requesting a new access token using the original access token.
Here are more details on the flow: Find the section titled Delegated User Identity with OAuth 2.0 On-Behalf-Of Draft Specification
Here is a code sample integrating this flow:
https://github.com/Azure-Samples/active-directory-dotnet-webapi-onbehalfof
Just to note, in this specific case, that the 401 error implies that you do not have the correct permissions for calling and accessing the API you want. Can you make sure you have selected the right permissions for the resource you want to access, for the client that you are accessing it with?
I hope this is what you are looking for!
I am currently developing an API that I plan to secure using oauth2.
I have chosen: https://github.com/lucadegasperi/oauth2-server-laravel/
I have managed to secure the endpoint (using before=>oauth in my api routes) by following the installation guide but I am at a loss as to how am I gonna be able to authenticate and access the endpoint.
I do understand that you will first need to request an access_token by sending a client_id and client_secret but what I don't get is where do I set those on the oauth server?
I see the oauth controller has endpoints for these like:
http://somedomain.com/oauth/authorize
http://somedomain.com/oauth/access_token
But I am clueless with what to do with them. I only managed to arrive at the conclusion that it needs a client_id, client_secret, and stuff about scopes.
Where can I set these values for the api client to use?
Thank you for your help in advance.
I don't know Laravel, but in general, the authorization endpoint (in your case, http://somedomain.com/oauth/authorize) behaves as described in RFC 6749.
The specification defines four flows. If you use Authorization Code Flow among the flows, you should access the authorization endpoint with the following request parameters.
response_type=code (required)
client_id={your-client-id} (required)
scope={space-delimited-scope-names} (optional)
redirect_uri={your-redirect-uri} (conditionally optional)
state={any-arbitrary-string} (optional)
For example,
http://somedomain.com/oauth/authorize?response_type=code&client_id=your-client-id&scope=profile+email
The authorization endpoint generates an authorization code and returns it to your browser.
The next step is to access the token endpoint (in your case, http://somedomain.com/oauth/access_token) with the authorization code which has been issued from the authorization endpoint. Like this,
POST
http://somedomain.com/oauth/access_token?grant_type=authorization_code&code=issued-authorization-code&client_id=your-client-id&client_secret=your-client-secret
Anyway, I recommend you read RFC 6749.