oAuth2.0 authentication using EWS throwing 401 Unauthorized - outlook

I have oAuth 2.0 implemented in java as per recommended in the following link https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-authenticate-an-ews-application-by-using-oauth.
The Azure application which I created to get consent was using "Exchange API" earlier. Since I am migrating to a new domain, I thought of Instead of migrating my existing Azure applications I can have them newly created and replace the applicationId wherever required. When I started creating a new application I didn't find "Exchange API" as an option for API Permission, so went with "Graph API" as "Exchange API" was not available.
If I use the old code where the scope is https://outlook.office365.com/Calendars.Read against the new application created (where API Permission is using Graph API) and create an OAuth token with ExchangeService as [ewsClient.Url = https://outlook.office365.com/EWS/Exchange.asmx] it is working as expected.
But when I change my Scope to https://graph.microsoft.com/.default (As I changed the API to Graph in my azure application, I thought my scope also has to be changed accordingly) and having ExchangeService as [ewsClient.Url = https://outlook.office365.com/EWS/Exchange.asmx ] it is throwing 401 at ExchangeService.bindToFolder() method from Microsoft ews-java-api jar.
Any suggestions on
what has to be changed to avoid 401.
Can I still use https://outlook.office365.com/Calendars.Read as scope and https://outlook.office365.com/EWS/Exchange.asmx as my ExchangeService URL even though the azure application which I use to generate the OAuth token is having API permissions through Microsoft Graph?

https://outlook.office365.com/Calendars.Read
This isn't a Scope that will work with EWS it sounds like you maybe use the Outlook V2 endpoint as that would be a valid scope and audience for that API (which has now been depreciated).Depending on what flow you using the only valid scope for EWS are EWS.AccessAsUser.All for delegate flows and full_access_as_app for Application (Client_credentials) flow. In the first doc you linked it give a method of modifying the manifest as they removed the method of adding the permission in the portal. Graph permission won't work in EWS so https://graph.microsoft.com/.default won't be a valid scope it may return a token but that token wont have a valid audience for EWS. If you using the Client_Crendentials flow and you have given full_access_as_app then you need to use https://outlook.office365.com/.default or for delegate flow you use https://outlook.office365.com/EWS.AccessAsUser.All. It sounds like from you code you may have either both EWS or some Outlook V2 code but you need to show some of your code. What might be an easier solve for you it to look at your old manifest and look at the Guid's of the permission being used you can actually cut and paste these into the new manifest then consent to those and everything will work.

Related

Authenticate Microsoft Teams Tab against external API

I'm working on a Teams Tab that requires access to my own external API, however I'm having difficulty understanding the best way to achieve authentication in the context of a Tab.
My API uses the standard OAuth2.0 workflow for getting an access token, but from the Teams Tab context it's unclear where I can safely store the access token after completing the OAuth flow. Also, I need to safely store the client secret for my API so that it's not visible in the client-side code.
So far I've tried using ADAL.js and the examples in https://github.com/OfficeDev/microsoft-teams-sample-complete-node without any luck.
I'm assuming I need to authenticate my API through the Azure AD but I'm unable to find where I'd register the my API's client id/client secret to be used by the above libraries. Is there a standard pattern used by Teams developers to safely + securely handle this type of authentication?

WebAPI 2 Authorize Roles with MSAL

I'm in throws of moving our security architecture from ASP.NET Core Identity to Azure AD V2 with MSAL.js. We used a lot of Roles with the ASP.NET Core Identity implementation and the information was managed in the database using the web application. The pattern I'm abandoning is similar to this one.
https://www.dotnetcurry.com/aspnet-core/role-based-security
Azure AD with MSAL is working. The tokens are being created and passed and the local Web API Endpoints decorated with the generic [Authorize] attribute are being honored as you would expect. Web API Endpoints decorated with [Authorize(Roles= "Fee, Foo, Fi, Fum")] are throwing a 401 unauthorized error.
I'm not sure where to go from here. Do I write a CustomAuthorize attribute override for Web API and go back to the database and grab the roles. (probably match the DB defined roles to the user based on email address)
OR
Is there a way to implement roles natively with Azure AD V2?
I'm not sure whats the best course of action from here. Documentation and Code samples seem limited. It would sure be nice to just throw a AD User in a Group and have the Group be respected as a Role in the Web API. On the other hand, It's nice to have Role delegation handled within the confines of the Web Application.
Any advice, experience or interest would be greatly appreciated.
Answer
Follow up to my question. #Marc , You're correct, after looking at the token the Roles are not present. Adding Roles to the token seems pretty straight forward. You need to Patch the graph schema to include them, Configure the roles and assign them to users as needed thru AAD.
Or that's how it looks at first glance. After digging a deeper, it requires a P1 or P2 Enterprise license which only costs an additional 6$ per month per user. This will literally double the cost of hosting email in the cloud for us.
Alternatively I wrote a CustomAuthAttribute for WebAPI and tied User & Roles together on the server backend. Roles can still be managed via the web application and users can still login using Active Directory Credentials.
I recall that the id token returned in implicit flow (the one you use with JS) does not include app roles (or groups). I cannot find any docs confirming that but see others who got around the issue (so the issue must be there) by using Graph to get the roles (or groups).
You can capture the token you receive from AAD and view it using https://jwt.ms to see whether roles are included in it.

Google API giving unauthorized token error

We have an application hosted in GCP which uses GSuite APIs to sync users from GSuite to our application and visa-versa using Service Account. It used to work well until recently some of our customers started facing issues.
We started getting
401 unauthorized. "Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."
There as been no change in our application and neither in the list of permissions granted. Following are the list of api access granted :-
https://apps-apis.google.com/a/feeds/domain,
https://www.googleapis.com/auth/activity,
https://www.googleapis.com/auth/admin.directory.group,
https://www.googleapis.com/auth/admin.directory.orgunit,
https://www.googleapis.com/auth/admin.directory.user,**
https://www.googleapis.com/auth/admin.directory.user.readonly,
https://www.googleapis.com/auth/drive,
https://www.googleapis.com/auth/drive.appdata,
https://www.googleapis.com/auth/drive.file,
https://www.googleapis.com/auth/drive.metadata,
https://www.googleapis.com/auth/drive.metadata.readonly,
https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly,
https://www.googleapis.com/auth/admin.directory.rolemanagement,
https://www.googleapis.com/auth/admin.directory.device.chromeos.readonly,
https://www.googleapis.com/auth/admin.directory.device.chromeos,
https://www.googleapis.com/auth/drive.apps.readonly,
https://www.googleapis.com/auth/drive.photos.readonly,
https://www.googleapis.com/auth/drive.scripts
The affected GSuite domains were working perfectly until yesterday. Also there are some domains which still work without any problem.
Can somebody please suggest what could the problem be. Is there any change in the APIs recently? Any help will be much appreciated.
"Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."
There are several ways to authenticate to Google.
web based applications
native applications
mobile applications
and service accounts
The clients you create for these types is different as is the code to use them. The message you are seeing above means that the code you are using does not match the type of client you have created.
Make sure your code is designed for use with service accounts and make sure that the credentials file you have downloaded from google developer console is in fact credentials for a service accounts.
Why it worked previously and suddenly stopped i cant tell you this is an error you will always get if your code does not match your credential type.
The last option would be to double check that all of those apis are enabled in the Google developer console for your service account project.

Access Not Configured. +1 API

I'm trying to get shares counts from Google+ using the Google+ API and catch only error:
Access Not Configured. +1 API has not been used in project 383866521277 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/pos.googleapis.com/overview?project=383866521277 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.
After that I visit recommended link and catch pos.googleapis.com not found. How to enable this API?
In order to access Google APIs you need to register your application on Google developer console. You have probably already created your credentials. The API key or Oauth2 credentials you created identifies the application to Google. The project that was used to create the API key or Oauth2 credentials you are using must have the Google+ API enabled.
Enable API:
What you have forgotten to do is to tell Google which APis you will be accessing. On the Left hand side look for "Library" find the Google+ api and enable it.
Error pos.googleapis.com
Means that you do not have access to the project 383866521277 or it was deleted. The person who created the project must enable the Google+ api for you. Remember this is denoted by the The API key or Oauth2 credentials you created and are using in your code.

Making an OAuth connection from a Windows application to a Google App Engine application

We have a Windows 7 Task Tray application that needs to access services in our Google App Engine application, and we are having difficulty making the OAuth connection between them work. For some reason our OAuth libraries that work with the Twitter and Tumblr OAuth implementations do not seem to work in this scenario with Google. Google is returning a 400 bad request response to the last step in the OAuth authorization sequence.
To debug the problem I am trying to use Google's OAuth 1.0 Playground page (http://googlecodesamples.com/oauth_playground/index.php). But I can't figure out what should be entered for the "scope" in step 1. If I enter the name of our GAE server the sequence will fail with the error message "Invalid scope". Clearly, choosing one of the provided scopes (the Google API services) is not an option for us.
Can anybody tell me how the OAuth scope designation should be set when accessing Google App Engine hosted services?
just for reference look at this blog,looks helpful in your case
http://ikaisays.com/2011/05/26/setting-up-an-oauth-provider-on-google-app-engine/
I think this Google Official Docs explains best how to set up an endpoint to your own appengine application. You question isn't very specific, but take note of the following that is being written in this document:
The scope of an authorization, how much the consumer is allowed to access, is for all of a single app. App Engine only supports whole-app scopes, and does not support more granular scope requests. When Google Accounts prompts the user to authorize a consumer, the prompt explains that the consumer is requesting permission to access the full app.
And did you set up OAuth on your domain?
The consumer performs OAuth actions using a set of standard web service endpoints. These endpoints use reserved paths on your app's domain. For example, if your app uses a Google Apps domain of www.example.com, the endpoints for the OAuth protocol begin as follows:
https://www.example.com/_ah/OAuth...

Resources