We are using Excel add-in in OfficeJS and wanted to implement login authentication with below requirements.
we have own on-premise server (identity),
need to achieve access and refresh token.
Kindly suggest any examples for the same.
An add-in is just a web application embedded in Office. so you would implement login auth exactly the way you would for any web application. If you are using OAuth 2.0, then for resources and libraries about how to do this, see Authorize external services in your add-in. The one possible exception is that some identity providers (Secure Token Services) do not allow their login page to open in an iframe. If that is the case with the STS that you will be using, then you will need to open the service's login page in a special dialog. For more information, see Authorize with the Office Dialog API.
Related
I am developing a Microsoft Office Add-in that is using Auth0 to manage user logins. I am using Google SSO (identity provider) in Auth0.
I was able to add the login capability to my app by following this example on github: https://github.com/OfficeDev/Office-Add-in-Auth0
However I am now trying to add functionality to log the user out. I am calling the logout endpoint through a cors proxy (i host my own proxy that i use) as so:
https://cors-anywhere.herokuapp.com/https://{MY_AUTH0_DOMAIN}.auth0.com/v2/logout?
federated&
client_id={MY_CLIENT_ID}&
returnTo={MY_RETURN_TO_URL}
The call will return a 200, but when I go to the login screen and sign in with google I am not presented with the screen to select my gmail. I am just logged into the app with the gmail i used the first time.
The only thing that logs the user out of their gmail (identify provider) is by manually "clearing the web cache" in the add-in.
I have tried following these instructions: https://auth0.com/docs/logout/log-users-out-of-idps
I setup the proper clientId for google, so that i am no longer using the dev keys.
Has anyone successfully added logout functionality for an identify provider with auth0 in an office add-in?
I am looking for a bit of direction here. I am building an ASP.NET Core 3.1 web interface to an existing jira tool that does some queries and presents status. For authentication, my calls to the server that retrieve data need proper jira credentials to operate. However, the API I am using never establishes a connection via logging directly into jira. It opens a connection in the code with the passed credentials.
So my question is, what is the proper way to do this in ASP.NET Core 3.1? I don't need someone to do all the work for me, just point me in the right direction. in WPF, I simply had the user enter their name and password and I established the connection object at startup.
Check out these docs. The user shouldn't be putting in their Jira creds in your app.
OAuth 2.0 (3LO) for apps
The app directs the user to an Atlassian screen that prompts them to
grant access to their data on the Atlassian site. The screen displays
the access being requested in the Atlassian product.
The user grants (or denies) access to their data on the Atlassian
site, via the screen.
The user is directed back to the external service. If the user
granted access, the external service can now access data (within the
specified scopes) from the Atlassian site on the user's behalf.
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 trying to write a C# console app that will register an application in Azure Active Directory. It should work just as the web application project creation wizard in VS 2013 when you Change Authentication and select Organizational Accounts in Azure.
Following the fiddler trace, I can see that it authenticates the user using wsfederation and an oauth2 token and then uses the graph.windows.net graph api to configuration the AAD directoryObjects service principal and application.
I have tried to use the sample Graph API app, but it requires the app be registered first so that I have the clientId (application id) and password (key) to send in the Acquire Token request using the Windows Azure AD Authentication Library for .NET.
I've tried using a bunch of the different Azure APIs but they all have my chicken and egg problem, I want to use an unregistered client application to register an application in AAD. I need to avoid Configuring Application Authentication and Authorization for the Graph API so that the user has no manual steps.
Does anyone know how Visual Studio does it, using just the user login with browser prompt or if there is a standard application id and password that can be used to access the graph API, like there is the standard login URL, https://login.windows.net/common? Some C# samples would be greatly appreciated.
This post does the Application creation, but requires a clientId and password, which I don't think I have.
You can't register a new application using the Graph API from an unregistered client. The only reason the VS2013 flow works is because VS2013 is already registered in a special way within Azure AD -- it's a first party application and has unique permissions. In my Fiddler trace, VS2013 uses a client ID of 872cd9fa-d31f-45e0-9eab-6e460a02d1f1. Technically you can use this client ID and the redirect URI of VS2013 to initiate sign-on with Azure AD. This still involves user interaction (the user has to authenticate via browser pop-up) so it doesn't meet your requirement for "no manual steps," but it's somewhat helpful for understanding the protocol flows and how registration works.
The bottom line is that if you want to call the Graph API without user interaction (client credential flow), the client needs to be registered with the proper application permissions.
I have a SharePoint 2010 web site configured for Claims only as the Replying Party to ADFS. I also have an ASP.NET application configured for Claims using WIF + Extension for SAML 2.0 CTP as the Replying Party to the same ADFS server.
If I navigate to SharePoint, I get redirected to the ADFS server (https://.../adfs/ls?...) and presented with a Windows Login prompt. If I then navigate in the same browser instance to my ASP.NET application, the redirect occurs quickly to the same ADFS server, automatically authenticates, and redirects back to the ASP.NET application without a security prompt. As in How to share authentication context between a SharePoint 2010 Site and ASP.NET applications.
The issue occurs when I embed the ASP.NET application within an IFrame in a SharePoint web part. When starting a new browser instance and navigating to SharePoint, I get prompted the windows login prompt. As the page loads up to the IFrame I then get a second Windows Prompt for the same server for the embed ASP.NET application. If I cancel the prompt I get a 401 Unauthorized in the IFrame. If I navigate to the ASP.NET application, I am not prompted and it logs in automatically. Navigating back to the SharePoint application, the page will load including the IFrame content without prompts.
The SharePoint Endpoint is using the WS-Federation Passive Endpoint to https://sharepoint:port/_trust/ with binding POST.
The ASP.NET application Endpoint is using SAML Assertion Consumer Endpoints https://aspnetapp/ with binding POST and Artifact.
The Claims passed from both contain all required for each application.
Does anyone know how to prevent the second login prompt when using an IFrame in SharePoint?
It now works as expected with single sign-on after updating to System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0 from the now built in WIF classes. I'm assuming there was a compatibility issue with the Microsoft.IdentityModel.Web.Saml2AuthenticationModule SAML 2.0 CTP extension that was never finished.
Just a shot in the dark but assuming the custom ASP .NET application and SharePoint are on two separate machines, then there may be some subtleties regarding kerberos given that the ASP .NET page is in an IFRAME - it could be that a kerberos ticket needs to be passed between SharePoint to ASP .NET.
HTH.
This is only a guess but I believe that this is because both sites, the Sharepoint site and the embedded asp.net site from the iframe, start to load in the same time.
As both are not authenticated, they both go to the Adfs. But because you are not authenticated, the Adfs starts the 401 challenge, asking for the authentication. However your web browser does not present both login prompts in the same time. Rather, you get the first login prompt and when you sucesfully login, from the very moment the Adfs will retain the authentication so that any other site coming for claims will get them for free. But the inner site, the asp.net one, has already started the login process! Your browser does not know this and forces you to continue login.
As a conclusion, my idea would be to have a sharepoint page which requires authentication and which then redirects to ANOTHER page which has the asp.net site in an iframe so that your browser will not try to start the login sequence for both sites at the same time.