I am using Office 365 to manage my calendars. I would just like to publish one of my calendars to my blog. Also, I would like to fully control the style of the calendar. I can enter API URLs into the browser and basic authentication to access my own calendars. So, I could do that from the server to build my calendar page using a server side http client. In this case, I don't really need the full power of OAuth2, which is mainly for letting multiple visitors manage their own content on a third-party site.
It would be nice if Microsoft's Office365 libraries would handle this scenario. It could also include a step where I register for a keys similar to the way Google Maps does. Or do they offer this already?
Does anyone know what steps to take so my scenario would work? Also, would I run up against any usage limits for a popular blog?
While the API is supporting Basic at the moment, that will eventually go away. You can definitely make your scenario work using the authorization code grant flow that's in place today, but it sounds like you may be more interested in the client credential flow which we are going to be releasing support for soon. That would allow you as the administrator of your Office 365 organization to authorize an app to access calendars in your organization without requiring user sign-in.
You register for client IDs and client secrets via Azure AD.
Azure AD is included with Office 365, and registering apps doesn't include any additional paid Azure services.
The client IDs and secrets obtained with the Visual Studio tool are permanent, and not just for debugging. Can you point me at the documentation that said otherwise so I can get it corrected? :)
Related
I have a React Application that uses Microsoft AD to authenticate users.
As a first step, and according to Microsoft Documentation, we need to register the application with the Microsoft identity platform.
This is inline with Microsoft Identity Platform Documentation, in this diagram we can see that for ALL types of applications (SPA, Web App, etc), we always need to configure an application in AzureAD:
This process is "cumbersome", and i'm trying to remove it by having the application installed automatically.
Several third-parties do this, such as Zapier, SpecFlow, etc.
Basically, they have a process where:
User logs in on Zapier
User is redirected to Azure AD sign-in page
User is authenticated and authorized
AzureAD shows the Consent Page
User consents
Application is installed on user's AzureAD
I've been reading and searching in Microsoft's Documentation, and i cannot find a single document that shows or even mentions this type of flow.
BUT, i know that this is possible, as there are several third parties that are doing exactly this, as Zapier, for example.
Can anyone point me in the right direction, there must exist some Microsoft document that explains how this process is done!
Apologies if this should be a comment, not an answer. I do not have enough SO reputation to write comments.
Zapier is published to the Azure Active Directory application gallery (1c76d9b0-0826-4b19-8706-29572657af1e). You can do this as well:
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/v2-howto-app-gallery-listing
If an application already exists in the gallery, it does not need to be "registered" in the user's tenant, as the registration definition is defined in the gallery.
Once an app is in the gallery, users can use it only if their tenant's administrators allow this, per the settings on this page:
Enterprise applications | User settings
https://entra.microsoft.com/#view/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/~/UserSettings
From the user's end, there are other governance controls that may impact the user's ability to use your app, but I think "register your app in the gallery" is probably what you're asking for.
I have created an azure function. I want this azure function to be only accessible for people who are using my Custom React Microsoft Teams Tab Application.
How can I do that
Thanks,
This is actually a very detailed question as there are many aspects to security, but here are some starting points:
you could look to ensure your users are, at least, logged in to Office 365, or even specifically to a certain tenant. MSAL would help with this, which is Microsoft's client-side Javascript authentication library for authenticating against Azure AD
You could look to add authentication into the Azure Function as well - see here for an example.
Using the browser's built in CORS capability is also a very easy thing to implement. Here's an example of that - it will block user browsers to only calling the function from your own domain (wherever your tab is hosted).
Of course, none of these is foolproof, but they should give you some good starting points.
I'm creating the user authentication in a web application, and I want to use Identity Server for resource protection.
The sample code and documentation shows how the user logs into Identity Server after creating an account for it. That is to say, they log in with their own Identity Server account. The quickstart even provides a UI.
But I don't want users of my application to have to log in to Identity Server, an external website. I want them to only have to log in to the web application.
So how to proceed? It just doesn't seem at all clear from the documentation how you're supposed to handle this scenario, which I would have thought would be the most common.
Do I just use a pre-defined API scope and user for token validation, holding for all the website's users? That doesn't seem to be very secure given that any user of the website or anyone with the client name and secret would have a valid token. Not sure what the point is in having the security if it's that easily worked around.
Or do I interact with my Identity Server instance somehow after the user is registered in the web application, and store the new user in a database? I can't find any mention of this in the documentation . It all seems to be very muddled to be honest.
Please could anybody shed light on some of this? What is the "standard" approach here? To have the user sign in to the external Identity Server website? That seems a great way to annoy your users.
If you only have one application and you don't intend to add more applications that needs to share users, then you should look at ASP.NET Core Identity
The whole point with OpenID-Connect/IdentityServer is to delegate the managing and handling of users/passwords (authentication) to a central entity. So individual applications don't need to deal with that complexity. IdentityServer is useful when you have multiple applications or if you have more complex integration needs. It is also perfect if you need to customize it to your own needs. If you don't need the customization part you can also outsource it to someone else like Auth0 that give you an IdentityServer like experience as a service.
In a mobile application we are generating some images that we would like to upload to the client's cloud.
The client is using OneDrive For Business, with all the 360 suite (I have no more information about it yet).
What we would like to do, is to be able to store the images in a OneDrive account, without the user having to sign in. All the documentation I found to authenticate to OneDrive includes an interactive sign-in process which we don't want:
https://learn.microsoft.com/en-us/onedrive/developer/rest-api/getting-started/graph-oauth?view=odsp-graph-online
I have found that for Microsoft Graph there is the possibility of using the app's own identity to sign in (only REST), but it is not 100% clear to me that this authentication can grant access to OneDrive.
https://learn.microsoft.com/en-us/graph/auth-v2-service
Since I am not familiar at all with Microsoft cloud infrastructure I would appreciate some info.
Is it actually possible to access a OneDrive folder authenticating with the app's own identity?
Yes it should be possible to work with Microsoft Graph API and One drive files using application identity (i.e. without a user sign-in)
REST API's that should help
Do know that there are many SDK's/Client Libraries available for Microsoft Graph API that you can work with depending on your platform. e.g. Microsoft Graph .NET Client Library. As you've mentioned Only REST, I'm giving links for direct REST APIs here.
Uploading files (upto 4 MB) - Upload REST API
Least permission required will be Files.ReadWrite.All (under application permissions and Admin consent will be required first for this application permission. In case you aren't familiar with consent process, take a look here: Azure AD Consent Framework and mention in comments, I can add a little more detail if needed)
Uploading larger files - Resumable Upload REST API
Authentication
From a flow standpoint you will need to make use of OAuth 2.0 Client Credentials Grant Flow to authenticate
NOTE: Please do note that this flow is meant only for confidential clients. So you shouldn't make use of it directly from a mobile client or even desktop client (like WPF or console application), as these are public clients which can not securely handle client secrets. Your mobile client should call a backend API, that in turn can call Microsoft Graph and uses client secrets, acting like a daemon using Application permissions.
At the end of this link there are code samples available for .NET Core 2.1 and ASP.NET MVC.
We want to build a central authority to do authentication and authorization for our various applications (.net). We see IdentityServer4 is open source and free, while Auth0 cost money. Does anyone use both of these? Can anyone provide suggestion which one to choose and why?
IdentityServer is a library that implements various authentication (not authorization!) protocols and let's you consolidate access control into a single system. You can host it in a typical ASP.NET webapp, console app or anything else, as long as the HTTP endpoints are available. It also lets you store the user data anywhere you want, whether in-memory, databases, flat files, the asp.net core membership system, or anywhere else.
Auth0 is a company that provides a managed service that handles authentication for you. They run the infrastructure and provide access through their website and APIs. It's similar to having someone run IdentityServer4 for you and there are several competitors like Okta for Devs, AWS Cognito, Azure AD B2C, Google Cloud Identity/Firebase, and more.
Choose IdentityServer if:
You want free open-source software.
You have the time and effort to run it yourself.
You want to control the backing data store (SQL database, Redis, JSON file, etc).
You want to manage all the data yourself due to regulations, privacy, etc.
You need complete control and flexibility around what happens during authentication (for example, merging user accounts in your database when someone signs in). It's all just C# code so you can do whatever you want.
Choose Auth0 if:
You want to save time and effort on implementation and operation.
Price is not an issue (as it can get expensive for some features).
The limited customizations offered by Auth0 are enough for your app.
You want the other features they offer like password-breach monitoring.
You don't want to manage user data, or don't mind having it stored by them.
Update as of Oct 2020 - IdentityServer is now a product from Duende Software with a new commercial open-source license to sustain development. There are other alternatives like OpenIddict that are still free.
Identity Server means building a server application to handle authentication and authorization, which can replicate what Auth0 does for OpenIdConnect (OIDC) there will be a few things to implement even if you use IdentityServer4. You will need to build that first, then integrate your application.
Auth0 allows you to integrate immediately with OIDC with additional & enterprise features.
Both of them implement federated protocols i.e. WS-Fed, SAML and OpenID Connect.
In order to use them your apps. need the appropriate client-side stack.
If they don't have this, you can't use the products.
The only alternative is pass-through, i.e. Auth0.
Or look at ADFS which has pass-through via the ADFS WAP.
If you do have the stacks, both will do the job.
idsrv4 does not have a user management portal e.g. create user, add group to users OOTB.
Auth0 does.
idsrv4 essentially adds features by code. Auth0 has config. via wizard.
idsrv4 is open source so you can customise to your heart's content. I find it really useful to bridge systems.
Azure AD is another option.