Will I be able to use the new REST File API from a service headlessly?
For example, I want to be able to create a service where the user gives consent once, and there-after the service may perform file operations (against sharepoint online) without explicit consent for months on end without intervention.
Such a thing is possible with other OAuth type REST apis (for instance the One Drive Rest API allows for it) by storing a refresh token and using it to get a new access token.
1) Is such a thing possible with these new APIs. The comment by "JTHAKE" in response to "Tdriver" here
http://blogs.office.com/2014/05/12/net-and-javascript-libraries-for-office-365-apis/ . seems to hint that what I want isn't possible but I'm not sure why not.
The new O365 rest APIs use the Common Consent framework in order to verify that the app has permission to use the APIs. This means that a user needs to first register an app in AAD & consent to the app's data use in the browser so that the app has the correct permissions. Once the app is consented to, completing the oauth flow headlessly will get you the right token to call the APIs from a service.
Related
Is there any way of authenticating a user via the Office 365 REST API, without registering an application first?
For example, the documentation of Microsoft Graph has numerous authentication scenarios, including how an application can
Get access on behalf of a user
but there is no such scenario for a user calling the REST API with some credentials (e.g., username and password) and gets authentication tokens as a response, so that they can subsequently use the rich functionality provided.
The Azure Active Directory Authentication Libraries (ADAL) provide user-level authentication functionality, but they do not expose the REST API.
There is no way to call the Microsoft Graph without registering an app first. All calls to the graph are authenticated using a OAuth2 flow (of which there are several) and all require an app to be registered.
For your question, I think we can use background daemons or services to get authorize the user.We can use the following steps:
Get access without a user.
We can refer to this document to learning more information.
2.Authorize the user
When we get the user's profile by using the access token in the step one, then we can authorize him by checking him is exist in our system.
I'm integrating several web sites/services into my application. I use iframes (or webview for Vue Electron) for UI integration and I also use API to implement cross-communication between those services.
At the moment I have to go through OAuth 2 authentication twice for each service: once as part of natural authentication in iframe and another when I ask the user to give me access to this service (for api reasons).
Is there any way to streamline this process?
The state of the art response would be to modify your application completely.
You should have 1 SPA application and not iframe
This application would authenticate to get OAuth2 token
This application would then call the backend (access multiple backend, or access on api management layer that call backends).
Thing is, with this you can have 2 strategies :
give all permission (scope) at 1st authentication
give the smalled scope possible at 1st authentication, then when needed "reauthenticate" (in fact validate new scope) to get new access token
When an API want to call another API, you have also 3 strategies:
you simply use the same client token the API receive to the service your API call (no human interaction needed)
your API generate a token from a service account (using ROPC authentication scheme) or via a client credential scheme (the access token will be valid but usually not be bind to a real user), (no human interaction needed). (the API will be the client of the 2nd API)
your identity provider have an endpoint to transform access token : Your API can give the client access token, and authorization server will transform this with the client_id of your API. You send this token to 2ndAPI ( token will show subject of your UI application, but client ID will be the 1st API clientId) (no human interaction needed)
Now if you use IFrame with multiple sub-application on the same domain (the domain need to be exactly the same!), it is possible to share the same access token for instance via local storage. (security is not top notch)
You will probably need to authenticate with a bigger scope list sometime but it is your only option. You will simulate a single page application, but issue is that you will have potentially different client_id depending first application you authenticate to.
Edit: Multiple authorization server
From your comment, you have multiple authorization server. One strategy could be to ask user to authenticate, your application can then get an access_token and a refresh_token.
Depending on your authorization server, refresh_token can be used a lot / on a long period of time, so that if you store it somewhere, the next time the user visit your application, your application can silently get an access_token from this refresh token. Your application have then access to remove api without newer interaction from your user.
Of course, this means you have to save this token the most safely you can.
By using OpenID Connect you could combine authentication and authorization in a one step and get both an id_token to logon your user to your app as well as an access_token to access APIs in a single authentication response.
I have used Auth0 for a while with success, I recently came across a new challenge: allowing external developers to access my API with credentials provided by my web app.
The current system comprises of:
a Web App (not a SPA currently) with Auth0 log in
a back end API with Auth0 api authentication
Currently there is a single client in Auth0. The user logs in on the website and when they call the API via the website the token is passed along in the headers.
My question is: what is the best way to allow developers to request direct access to the api, in a self service manner on my website?
I see two paths forward, either create a client for each developer application via the Auth0 management API (github style), or request a token on behalf of the developer with a VERY long lifespan (like AppVeyor).
I'm assuming that your API provides functionality and/or resources that are associated or owned by an end-user, and you want to allow other application to also access this data on behalf of each end-user. If this isn't the case, and you API is general-purpose and does not require the notion of an end-user identity then other approaches like API keys could also meet your requirements.
Considering the end-user delegation scenario, the approach I would recommend would be going with the creation of separate client applications within Auth0. Like you said, you could automate this process through the Management API so that this process could be handled in a self-service way. Despite being self-service, the application that enabled the registration could still apply constraints in order to make sure only eligible developers could obtain the necessary information to then obtain access tokens to access the API.
This has the benefit that if you wanted to stop an existing developer from using your API you could just remove the associated client application and they wouldn't be allowed to request access tokens anymore and the ones they already had would be short lived and soon expire. This requirement is more complex to implement when using long-lived tokens because they would need to be revoked/blacklisted.
A final note, if these applications don't require to act on behalf an end-user when calling your API and you would prefer to still accept access tokens instead of using a different approach like API keys, then you can consider registering client applications meant to use the client credentials grant.
Is there any method to modify i.e. playlist by Web API by with console based application in Client Credential Flow ?
https://developer.spotify.com/web-api/authorization-guide/#client-credentials-flow
Propably not, but maybe I am wrong ? I want to modify only my user's data.
Here I created issue at API specification
https://github.com/spotify/web-api/issues/165
One of the benefits with the Client Credentials oAuth 2.0 flow is that applications can make authenticated requests to a web service without a need to involve an end user. Since a user isn't involved, the requests that can be made from the application is limited. For example, using Spotify's API, you can still make requests to retrieve track metadata, playlist contents, and search for albums. Any endpoint that requires a scope can't be used since it requires user interaction.
So using Client Credentials simply doesn't make sense if you're interested in making requests on behalf of a user, or if you want to access private data since the user needs to give you permission first.
You need to use Implicit Grant or Authentication Code Flow for this. I advise that you read further about the supported oAuth 2.0 flows in the Authorization Guide. One of the benefits of using the Authorization Code flow is that you'll also retrieve a new refresh token, which you can use to retrieve access tokens indefinitely. It however requires you to write a web service that accepts an authorization code and exchanges it for the tokens. The Implicit Grant flow doesn't return a refresh token, so it's only possible to use for one hour until the access token has expired.
I have an application with users/password (not developed by us) that calls a web service to inform us when a new user is created. This web service should enable us to create automatically a user through the google Directory API service to create an account on the Google Apps For Education.
How can I do that without using OAuth but using only login/password for the admin user of the Google Apps account ?
I know to update CSV file to create/update accounts in Google Apps but would need to create the accounts on Google without doing manual upload and batch.
Thanks for your answer.
The old ClientLogin authentication method for Google APIs is deprecated and is not supported by the Admin SDK Directory API.
You should use OAuth 2.0. Once you have the OAuth 2.0 refresh token for your script, you don't need to reauthenticate the user each time, just grab a new access token if the current one expires.
You may also be able to take advantage of existing applications that already perform the OAuth work for you like GAM.
I just did this exact same thing in a GAfE domain. I needed to create 60,000 accounts quickly, and have them placed in specific organizational units (schools). I'm now putting together a series on how to make sense out of Google Apps for Education using the API explorer and OAuth 2.0.
Basically, you'll need to forget passing user/pass credentials using the API. You'll need to create an OAuth 2.0 ID (web application), and enter a redirect URI (the callback page that will process the request after authorization has been granted). At this point, you'll need to compile a URL string with the following information:
Base URL for the authorization request
data scope
client ID
response type
redirect URI
See the example below:
https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/admin.directory.user&client_id=your_client_ID_copied_and_pasted_from_the_API_console&response_type=code&redirect_uri=https://www.example.com/callback.php
Once authorization has been granted, you'll be passed a code in the URL that you'll need to exchange for an ACCESS TOKEN using a POST request to https:// accounts.google.com/o/oauth2/token. The response will include the access token that you can then use in your POST request to the directory.users.insert API.