We have a web application that needs to synchronize scheduled events with a user's Google calendar. A Windows service will add/edit/delete Google calendar events for the user.
We are considering...
In our web app we authenticate the user with the Google oAuth2 JS libraries
Collect a token once the user has allowed our app to work with their calendar
Save that token server side, so a Windows service can then update the user's calendar.
Is this workable? Also, how do we renew expired tokens?
This article explains how to do it.
https://developers.google.com/identity/sign-in/web/server-side-flow
TL;DR
Related
OK.
So I am building a simple app for a friend. The biggest requirement for this app is that he wants a user to be able to go to his site and create an event on his google calendar. I have let him know that this calendar will have to be made public and he is fine with that. I created an API Key with google and the first call against the API with the API Key to get calendar events for a given day works fine. The second request, a post, returns :
err(401)"API keys are not supported by this API. Expected OAuth2 access token or other authentication credentials that assert a principal."
It doesn't make sense that his website would be an OAuth app because that would require the user have a gmail account.
There has got to be some kind of way to make this work ...
Thanks Everyone
I just want to make a post request to Google Calendar API using an API Key.
API keys only give read access. If you want write access you need the permission of the owner of the calendar
options
Create a google workspace account and use a service account with domain wide deligation
use Oauth2 have your friend auth it once store the refresh token and use the refresh token to request a new access token when ever you want to write to the calendar
neither option will work with client side JavaScript switch to a server side programming language
Using a simple C#/WPF application and the SharePointPnPCoreOnline I can call the GetWebLoginClientContext() method which opens up a window for the user to authenticate via MFA to a given SharePoint site. From that point on I can query the SP site based on the users level of access. The convenient thing about this approach is that I don't have to register my WPF application with Azure AD, give it permissions, get a client ID, client secret, yadda yadda yadda.
Is there a library that will similarly allow me to authenticate a user via MFA so that I can access the Graph API based on their permissions without the AAD app registration requirement from a C# client application? How about a JavaScript application?
This is not possible, to access the graph api, (for a work or student account) there must be an app registration to give you permissions to those endpoints. even the "graph explorer" has a registered application.
Even with your sharepointpnpcoreonline, that likely authenticates against an app registration/service principal, its just that its microsoft trusted app registrations, so it's hiding it in the background from you. if you were to check in your azure ad enterprise applications under microsoft applications, there are various service principals for sharepoint online for example.
Long and short of it is that you need to have an app registration/service principal to access graph api endpoints. you don't necessarily need a client secret though, as that depends on your specific application and the authentication flow you choose to use in your app registration.
I have enabled SSO using Azure Premium AD with Google Apps, i can login to Google apps when I go to browser and click my apps however I need to get data programmatic after I login into O365. Instead of clicking my apps i need to use a programmatic snippets (ex., javascript) query some data from google apps or any configured SaaS based apps.
You can try to use adal for js to authenticate and authorize your users. You can write a initialization functionality in your client application using javascript. When the document is loaded, check whether the user is signed in, if so, call your additional APIs, if not, use adal to login.
I have a scenario that I think should be fairly simple, yet I'm not finding a solution and wondering if someone can point me in the right direction.
The setup:
1) SharePoint online website (user must be authenticated to see page)
2) .NET MVC Web API service endpoint (user must be authenticated to get data from the service)
Both of these authenticate using the same Azure Active Directory. The Web API has been registered in Azure AD.
The problem:
I would like to put some javascript on a SharePoint Online page (not a Sharepoint Add-in, not an AngularJS SPA) that will make an AJAX call to the Web API using the logged in user's credentials without any kind of user prompt (since this is an ajax call, the user won't see the prompt anyway).
I've tried looking into the ADAL libraries, but all the JavaScript ones I can find require the use of Angular and require the user to authenticate a second time. I've found some documentation using OAuth 2.0, but (from what I can tell) require you to get the client to authorize the Sharepoint Online page to act on their behalf - which the user will not be able to consent to because it's an AJAX call and the consent page is not displayed in the browser (and it's still doing this despite having the app already approved by an administrator in Azure AD).
It seems to me the user shouldn't have to leave the SharePoint page and shouldn't have to enter their credentials a second time. I believe there should be some way that the log-in to SharePoint Online should also be able to be used as the log-in for our in-house app.
If someone could just point me in the correct direction, I would be very much appreciate it. Thanks in advance.
Normally, if we call the resource which protected by Azure AD, we need to authorize the app via OAuth 2.0.
Were you able to put a hidden iframe in the SharePoint online page? If it is possible, then we can use the Azure AD implicit flow get the token through iframe, and we can call the REST which protected by Azure AD via the token return by iframe. To enable the implicit flow, we need to download the application manifest from Azure portal and switch ‘oauth2AllowImplicitFlow’ to true.
And if you were only developing a single tenant which doesn’t require users to consent the app. Here is the HTML code request the token from a Iframe for your reference:
<iframe width="0" height="0" id="oauthHideIframe" src="https://login.microsoftonline.com/{tenantId}/oauth2/authorize?response_type=token&client_id={Client_Id}&redirect_uri={redirect_Url}&resource={your web api app url register on the protal}"> </iframe>
And to pass the token from iframe to the parent window, we can use the window.postmessage which allow the corss-orignal communication.
So I can get all necessary data from my server when username and password are provided (zumoJwt token, user id and auth identity), but I still cannot get the user id property from the user object at the server side. I'm trying to set the user as follows:
Ext.azure.Authentication.setCurrentUser({id: res.id, token: res.token});
Where res.id is the user id and res.token is the server generated zumoJwt token.
So my question here is as follows: How can I set these values properly to proper place in order to authenticate to the server with my custom authentication service?
The Sencha Touch Extensions for Windows Azure are built to connect via oAuth to the Azure Mobile Services, and therefore only support the oAuth providers available from Azure (Facebook, Twitter, Google, Microsoft).
Calling Ext.azure.Authentication.setCurrentUser() literally does nothing except store those values locally in HTML5 localstorage. Those values might get added to HTTP request headers later (if useHeaderAuthentication is set to true)... but these Azure extensions for Sencha Touch aren't going to allow you to use a custom oAuth provider.
Does Azure Mobile Services even allow you to use a custom authentication service? I know the Active Directory integration is new, but the Sencha Touch extensions don't support that yet.