I want to integrate users google calendar with my web app. I have been looking through the google docs but at this stage it is not clear whether i can use the simple drop in java-script library Auth the user and use that Auth token on my server for simple API calls to the calendar API?
You may want to check this Google Calendar API Quickstart for reference.
Every request your application sends to the Google Calendar API must include an authorization token. The token also identifies your application to Google. Your application must use OAuth 2.0 to authorize requests. No other authorization protocols are supported. If your application uses Google Sign-In, some aspects of authorization are handled for you.
After the initial user authorization, calls to gapi.auth.authorize that use immediate:true mode will obtain an auth token without user interaction.
Hope this helps!
Related
Based on the documentation details for MSAL (Azure AD) mentioned at : https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/MSAL.NET-supports-multiple-application-architectures-and-multiple-platforms#msalnet-is-about-acquiring-tokens-not-protecting-an-api
I am working on POC : ASP.NET Web App accessing Custom REST API protected by Azure AD.
The link mentioned above says that MSAL.NET (Microsoft Authentication Library for .NET) enables developers of .NET applications to acquire tokens in order to call secured Web APIs. These Web APIs can be the Microsoft Graph, other Microsoft APIS, 3rd party Web APIs, or your own Web API.
Based on the above definition is it good to assume that MSAL will be helping in maintaining a token cache and refreshes tokens for you when they are close to expire in case of the Custom REST APIs also.
Can anyone help me here by providing their guidance on it further.
MSAL and Azure AD don't give special treatment to MS Graph API tokens (except the ability to use a short name for scopes).
It can refresh any of the tokens as long as the way to refresh is still valid.
In the case of implicit grant (used by MSAL.js 1.x), the user must have an active AAD session in the browser.
In most other cases you use a refresh token to get a new token; as long as the refresh token is still valid, you can get a new token even after the access token has expired.
I'm using the linkedin rest api.
The browser that will be used by the users will have different users logging in
on it so i need to be able to invalidate the access token.
I know with the javascript api i can use IN.User.logout(); and it works.
What is the equivalent in the OAuth2 linkedin rest api ?
I'm working on a Google home application using an external API. I need the current user to be logged in and linked with the external API (access/refresh token provided by the external API).
My approach:
Setting up a firebase application
The google home app lives within the functions folder.
I would set up a page where the user would first sign in with his Google account using firebase.auth(), then his external API account (using the external API Oauth).
I would then create an entry in the firebase database to store, for each user, an access/refresh token provided by the external API.
This is where I'm a little confused and stuck. I've managed to setup the sign-in page (Google sign-in, then External API Sign-in) and store it the the firebase database (/users/{google_uid}).
Now that it's in the database, how do I set up the authentification in the Google home app?
Thank you!
First, you need to have a project in console.developers.google.com and activate the Google Actions API in your project. Then, you should follow these steps:
Whitelist the following redirect URI in your API:
https://oauth-redirect.googleusercontent.com/r/
In your API.AI project go to Integrations and enable the Actions on
Google Card.
In the setting of the Actions on Google, place your project ID and
select Sign in required for the welcome intent and any other
intent the user needs credentials.
Below, you will find the OAuth2 fields, like clientID, client
secret, authorization URL and token URL. Fulfill it with the OAuth2
information of your API and Authorize the application.
After you authorize, you can Preview the application and it will be available in your Google Home device, and when you invoke for the first time, it will provide a card in your Google Home app to do the linking. If you don`t have a device, there is a Web Simulator where you can test your Action.
For more information access the actions on google documentation.
There are a few issues with how you're thinking about account linking with Actions On Google and Google Home. Google Home doesn't give you direct access to the Google account - instead, it acts like a web browser and the account linking process requires you to issue an OAuth2 token to the Home "browser" for it to use in the future.
If you have control over the external API, and it issues OAuth2 tokens (which it sounds like it does), you can skip the Firebase portion completely. You just need to configure API.AI with the OAuth2 information for this external service - the client ID and secret, the URL for the login page and for the token exchange page, etc. In this case, your webhooks will be called providing the OAUth2 access token that you should pass on to the external API when you're calling it. The details are in the Actions for Google documentation Account Linking documentation.
If you do not have control over this API, you may need to provide a basic implementation of an OAuth2 server that can hand out auth tokens (either ones you create or ones that can be used to get the auth tokens from the external API). Your webhooks will then be called with these OAuth tokens, and you should use the token to find the token to use to access the external API. You have some options to implement this, and these options are discussed at OAuth2 Account Linking Overview in the Actions for Google docs.
I've been reading through a bunch of documentation for using OAuth with Azure AD, but am still completely confused about how to properly implement things for my situation. Hopefully someone can steer me in the right direction.
I have created an ASP.NET Web API application that uses the EWS Managed API to access Exchange on behalf of different users. My application exposes endpoints such as /Mailbox/Messages and /Appointments with the intent that some front end web application will eventually use them to retrieve a user's emails and appointments. Currently the endpoints are working using basic http authentication, but I'd like to update them to use OAuth. The application has been registered in my Azure AD instance and I've configured it to require the "Access mailboxes as the signed-in user via Exchange Web Services" API permission.
Since the front end hasn't been implemented yet, I've been trying to test by manually calling the authentication endpoint. This prompts me to log in and provide consent. If I consent, I'm redirected to the callback URL that I provided when I registered the app with the authorization code contained in the query parameters. I'm still not quite sure how I'm supposed to be using this callback, but for the sake of testing I currently have the callback redeem the authorization code for an access token. This is done by calling the AcquireTokenByAuthorizationCode method on an instance of the AuthenticationContext class and providing my application's id and secret. Again, just for the sake of testing I return the access token to the browser. I can then call my aforementioned endpoints (after some modifications) with this access token and get the emails for the user. I'm guessing much of this is not the correct way to be doing things.
Some of my points of confusion:
What should the callback that I registered in Azure AD actually be doing when it gets the authorization code? Is this intended for a different type of application? Perhaps one that isn't just playing the role of a middle man.
I'm trying to make my application somewhat RESTful, so I don't want to have to maintain the access tokens on my end between requests. As such, does it make sense for my endpoints to expect that the access token be provided in the authentication header for each request? If so, does that mean the front end application should be responsible acquiring the access token and passing it to me?
Being completely new to OAuth and Azure, I'm not sure if any other details are pertinent, but I can provide more information as needed.
What you are implementing is this scenario: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-authentication-scenarios#daemon-or-server-application-to-web-api
Here's how it works:
Your client app redirects the user to sign in at the authorization endpoint
Your client app gets back an authorization code (if using the auth code grant flow, there are others)
The client app exchanges the code for an access token for your API app
It will need to provide its client id and secret along with the code and the API's resource URI to get it
The client app calls to your API app, passing the access token in the Authorization header
Your API app then validates the access token, and requests for another access token from Azure AD for the Exchange API
It will pass the access token sent by the client app, along with its client id and secret and the Exchange API's resource URI to Azure AD
Your API app receives an access token so you can call to the Exchange API as the user
And to answer your two questions:
Authorization code flow is not used with APIs, only with apps that have a user signing in, thus the redirect URL is basically never used
Your API can and must expect and authenticate the access token for it to be in every request. But the access token it uses to call the Exchange API can and should be cached on the API's side. This is provided out-of-the-box with ADAL, though the tokens are only in memory.
I wrote a server side application that access a specific Google Calendar. Unlike most services out there that access visitors' calendars using OAuth2.0 proxy authentication, my application needs to access my calendar. Therefore I am using username/password authentication on the server.
Now I need to register calendar push notifications to call a web hook when the calendar is updated. All the examples I found are using access token, which I can't get from username/password authentication.
1. Is there a way to register a calendar web hook not through API but rather from some service?
2. Is it possible to get access token based on username/password authentication?
3. Is there an API to register a web hook on google calendar using username/password?
Thank you
So far I know what you want is not possible. My I suggest that you use OAuth with a refresh token on your server side application. You'll just have to grant your application access to your calendar once and your server will be able to access your calendar until you or it revokes access.