I'm developing a Web API that needs create, read, update and delete privileges on OneDrive for Business sites using REST.
So far my understanding is that an Azure Application will need to be registered within Azure for this
WebAPI.
Once registered the Application will have a client ID and secret key that can be used as part of OAuth. Also within Azure it can also be given the permission to call the SharePoint 365 API. (Provided the authenticated user is also authorized).
MSDN has code examples in which using the Application client ID within OAuth the client gets redirected to a login page for authentication. Once they enter in their username and password they are redirected back to the web application.
http://msdn.microsoft.com/en-us/library/azure/dn646737.aspx
As I am developing a web API I do not want any redirects to login pages. Instead I would like to automatically authenticate using a service account. (Which will have appropriate permissions within the OneDrive for Business site).
Does anyone know how this can be done or point me in the direction of some code samples?
Thanks
Service to Service (app only) grants aren't possible today for SharePoint with AzureAD OAuth. We only allow app + user grants.
This is on our radar - please stay tuned.
Related
I went through the documentation of smartsheet api third party authentication.
Steps are :
1. Register into developer tool.
2. Create an app.
3. note down client id.
4. From the application code call "authorize" api with client id.
5. smart sheet will redirect to consent page.
Now here I am confused. as to the API we will be called using Application's client id, how it is related to user who is access my web application. Because the app which I created in developer tool has access, api will works. Doesn't matter who is logged into my web application and has access to work sheet or not.
How smartsheet will know which user is trying to access the sheets because in the API we are just passing Developer App client id.
Or How Developer App can access logged in user's sheet.
Am I missing something?
The consent page will urge the user to login the system if the user has not logged in the system yet. Then, the system will ask the user whether he grants permissions to the client application or not. If permissions are granted, the system will issue a token which denotes "The user has granted the permissions to the client application". This is a basic concept of OAuth. Please read "The Simplest Guide to OAuth 2.0".
I recommend reading this section of the documentation: https://smartsheet-platform.github.io/api-docs/#third-party-app-development
Essentially, your application grants user access-scopes on a per-user basis. Your app needs a developer account. Your users need some kind of Smartsheet plan. Does that help?
I'm creating a demo application in .NET Core 2.1, which uses Azure AD B2C to login with Facebook, all good there, however, I would like to get the facebook access token to be able to invoke facebook api, I thought it would be added to claims or at least have access to an event like OnAuthorizationCodeReceived, where you would retrieve the access tokens, though so far I see no way to do it.
Is there any way to retrieve the facebook access token through azure b2c, if not, what would be the best recommended alternative?
Thanks.
It seems it is now possible to get the Identity Provider Access Token as a claim using Azure B2C, check Pass an access token through a user flow to your application in Azure Active Directory B2C
Currently, an access token from the external identity provider (e.g. Facebook) can't be passed through Azure AD B2C to your client application, i.e. this isn't a supported scenario as yet.
The only alternative is to implement a direct federation between your client application and Facebook.
I have an azure mobile all that uses authentication/authorization with facebook, everything is setup and working on my mobile app, I’m able to authenticate with facebook and get an access token.
I also have a web app (ODATA) hosted in azure and also uses authentication/authorization with facebook and its also working fine if I try to access the ODATA service it redirects me to facebook to login.
According to this article (https://azure.microsoft.com/en-us/blog/announcing-app-service-authentication-authorization/) I should be able to silently or programmatically send the access token from the mobile app to the web app by sending a json with acces_token key.
The may question is how I do this, is that access token in the header or where should I write it I can find any information from it. I would really appreciate a code example or an article that can guide me to accomplish my task
The may question is how I do this, is that access token in the header or where should I write it I can find any information from it. I would really appreciate a code example or an article that can guide me to accomplish my task.
Based on my understanding, you are using Client-managed authentication for independently contacting the facebook then retrieve the access_token from facebook, then you could leverage the access_token to login with your azure mobile app backend.
Also, you have a Azure Web App uses authentication/authorization with facebook and use the same facebook App ID. Then you want to leverage the access_token in your mobile client to access your another Azure Web App. At this point, you could login with your azure web app and retrieve the authenticationToken as follows:
POST https://{your-app-name}.azurewebsites.net/.auth/login/facebook
Body {"access_token":"******"}
Then, you could leverage the authenticationToken and set it as the x-zumo-auth header when accessing your azure web app as follows:
Get https://{your-app-name}.azurewebsites.net/api/values
Header x-zumo-auth:{authenticationToken}
Additionally, you could create your custom Web API endpoints within your azure mobile app, details you could follow adrian hall's book about Custom HTTP Endpoints.
I have a REST service that my mobile app uses to authenticate when the users click on the Facebook or Google icons.
The service accepts the user's id from the provider and checks if it exists on the database and then issues the access_token to be used for the other methods.
The problem is that I just thought that it could be pretty easy for someone to intercept the calls and discover which service authenticates and what the user id is and then call it with to get a token.
How can I avoid this?
I think you just need to separate the authentication and authorization functions. You can let Google (Google Sign-In) handle authentication. If you follow the API they will securely authenticate the user and send you the token which you can validate.
Once you know who they are for sure, your site can safely authorize that user approriately. For example, they might be an existing user, need to make an account, be an administrator. You can make those authorizations on your site based on the user authenticated by Google (in my example).
Twitter, Facebook and others do the same. Also see OpenID Connect.
I'm building a web service for use as an api component in web sites or apps built by others.
I am building a set of functionality that my clients can use on their sites for their users, but which are served by my application.
One of these services is user login. I intend to support multiple types of logins, and provide the client application a user token once the user is logged in. So the client application only has to implement one login interface, but they get a variety of oauth2 strategies for it.
To make this work with their google or facebook accounts, they would have to provide my app with their application id and secret key. Entering a secret key on someone else's site, even for integrating with your own site seems dangerous. They call it a "secret" key for a reason.
I have found one web service which seems to be doing something similar to what I am planning to do:
https://www.authic.com/documentation/google_oauth2
They have a configuration page for client accounts where the user enters oauth2 credentials to enable the Authic oauth2 login pages on behalf of the client app.
What are the security concerns to be aware of with this kind of service, and can the client app use a service like this safely? If it can be used safely, what is required for safe use? I think the app doing the oauth2 interface would be able to do other things on behalf of the client app, since it has an app secret, and the client app owners would have to trust that this was not happening.
The alternative to this strategy seems to be using my own application id with oauth2, and having the client apps redirect to my app's login page. Then the user will see the oauth2 permissions page with my app's logo instead of the app they were intending to log in to.