Hi Malaka , According to the my research there are two ways to request access tokens from Azure AD, Authorization Code Grant Flow and Client Credentials Grant Flow. In the implemented connector (OutlookMail), I am be able to get access token using "Authorization Code Grant Flow".
In the Client Credentials Grant Flow, I have followed these two docs. [1] https://msdn.microsoft.com/en-us/library/azure/dn645543.aspx [2] https://blogs.msdn.microsoft.com/exchangedev/2015/01/21/building-daemon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow/ Using [1] , I am able to get access token and using this, I could not access Outlook Mail API resources. Then I contacted Microsoft support team and they suggested that "needs to sign the token with a cert" and "A symmetric key is not sufficient for App Tokens accessing Office 365." After that I followed [2] . We need to - Configure a X.509 public cert for your application. - Get the base64 encoded cert value and thumbprint from a .cer X509 public cert. - Update the manifest file in the Azure Management Portal using this value. - Generate un-encoded JWT token. Using this value , I am unable to get access token. It shows error on client_assertion which value is JWT token. [3] https://github.com/mattleib/o365api-as-apponly-webapp [4] http://i1.blogs.msdn.com/b/exchangedev/archive/2015/01/21/building-demon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow.aspx I tried on generating X.509 certificate, getting base64 encoded values (base64Thumbprint,base64Value and keyid) and JWT token. When we used Client credential flow , manually we have to do these thinks before call endpoint to get access token. After that I tried with windows platform and I got same error in JWT token(client_assertion). Give me any suggestion. *Thank youVivekananthan Sivanayagam* *Associate Software Engineer | WSO2* *E:[email protected] <e%[email protected]>* *M:+94752786138* On Mon, Apr 4, 2016 at 12:20 AM, Vivekananthan Sivanayagam < [email protected]> wrote: > Hi Malaka, > > I tried OAuth2 client credential flow to get access token as > above-mentioned (Service to Service Calls Using Client Credentials [1] ) > and I was able to get access token. using this access token when I tried to > access Outlook Mail API resources, getting "401 Unauthorized" error. > > *ERROR*: > > 401 Unauthorized > Content-Length: 0 > Server: Microsoft-IIS/8.5 > Set-Cookie: exchangecookie=a95b0bfc4c004a05b669839663172bf0; path=/ > WWW-Authenticate: Bearer > client_id="00000002-0000-0ff1-ce00-000000000000", > trusted_issuers="00000001-0000-0000-c000-000000000000@*", > token_types="app_asserted_user_v1 service_asserted_app_v1", > authorization_uri="https://login.windows.net/common/oauth2/authorize";, > error="invalid_token",Basic Realm="",Basic Realm="" > request-id: 1ae17dac-e283-47b6-af79-a0aff6a1283a > X-CalculatedBETarget: PS1PR01MB0907.apcprd01.prod.exchangelabs.com > X-BackEndHttpStatus: 401 > x-ms-diagnostics: 2000001;reason="The access token is acquired using an > authentication method that is too weak to allow access for this > application. Presented auth strength was 1, required is > 2.";error_category="invalid_token" > X-DiagInfo: PS1PR01MB0907 > X-BEServer: PS1PR01MB0907 > X-Powered-By: ASP.NET > X-FEServer: SG2PR06CA0019 > X-MSEdge-Ref: Ref A: 9A2ED005E78B485B975983A0AC0B5F34 Ref B: > 122A6D0474C332F38CC3CD2B23B774C6 Ref C: Sun Apr 03 06:02:08 2016 PST > Date: Sun, 03 Apr 2016 13:02:08 GMT > > [1] https://msdn.microsoft.com/en-us/library/azure/dn645543.aspx > > [2] > > https://blogs.msdn.microsoft.com/exchangedev/2015/01/21/building-daemon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow/ > <https://blogs.msdn.microsoft.com/exchangedev/2015/01/21/building-daemon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow/> > > [3] > https://msdn.microsoft.com/en-us/office/office365/howto/building-service-apps-in-office-365 > > > > > > *Thank youVivekananthan Sivanayagam* > > *Associate Software Engineer | WSO2* > > *E:[email protected] <e%[email protected]>* > *M:+94752786138 <%2B94752786138>* > > On Thu, Mar 31, 2016 at 10:37 AM, Malaka Silva <[email protected]> wrote: > >> yes >> >> On Thu, Mar 31, 2016 at 10:23 AM, Vivekananthan Sivanayagam < >> [email protected]> wrote: >> >>> Hi Malaka, >>> >>> These are for "Azure AD Token Lifetime" >>> >>> - Access tokens last 1 hour >>> - Refresh tokens last for 14 days, >>> >>> If we use a refresh token within those 14 days, you will receive a new >>> one with a new validity window shifted forward of another 14 days. We can >>> repeat this trick for up to 90 days of total validity, then we’ll have to >>> re-authenticate. >>> >>> When we request additional access tokens with a refresh token , we can >>> get new access token along with refresh token. >>> >>> Do we have to take the new refresh token to replace the old one and >>> store in a registry? >>> >>> >>> >>> >>> *Thank youVivekananthan Sivanayagam* >>> >>> *Associate Software Engineer | WSO2* >>> >>> *E:[email protected] <e%[email protected]>* >>> *M:+94752786138 <%2B94752786138>* >>> >>> On Wed, Mar 30, 2016 at 10:56 PM, Vivekananthan Sivanayagam < >>> [email protected]> wrote: >>> >>>> Hi Malaka, >>>> >>>> As you suggested , there are two types of consent , User Consent >>>> (consent provided by an end user), Admin Consent (consent provided by an >>>> administrator). When we call the Authorization Code Request , we can set >>>> using "prompt" parameter. Possible values are >>>> >>>> - login: The user should be prompted to re-authenticate. >>>> - consent: User consent has been granted, but needs to be updated. >>>> The user should be prompted to consent. >>>> - admin_consent: An administrator should be prompted to consent >>>> on behalf of all users in their organization. >>>> >>>> >>>> >>>> https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=xxxxxxxxxxxxxxxxx&redirect_uri=http://www.wso2.com&prompt=login >>>> >>>> >>>> [1] https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx >>>> [2] >>>> https://blogs.msdn.microsoft.com/exchangedev/2014/03/25/using-oauth2-to-access-calendar-contact-and-mail-api-in-office-365-exchange-online/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> *Thank youVivekananthan Sivanayagam* >>>> >>>> *Associate Software Engineer | WSO2* >>>> >>>> *E:[email protected] <e%[email protected]>* >>>> *M:+94752786138 <%2B94752786138>* >>>> >>>> On Thu, Mar 17, 2016 at 12:52 PM, Vivekananthan Sivanayagam < >>>> [email protected]> wrote: >>>> >>>>> Hi Malaka, >>>>> >>>>> Noted. >>>>> >>>>> >>>>> >>>>> >>>>> *Thank youVivekananthan Sivanayagam* >>>>> >>>>> *Associate Software Engineer | WSO2* >>>>> >>>>> *E:[email protected] <e%[email protected]>* >>>>> *M:+94752786138 <%2B94752786138>* >>>>> >>>>> On Thu, Mar 17, 2016 at 10:58 AM, Malaka Silva <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Vivekananthan/Thulasika, >>>>>> >>>>>> In this typical OAUTH flow you mentioned, there is an user >>>>>> interaction. >>>>>> >>>>>> But for SAAS app use cases MS has provided Admin Consent to access >>>>>> the api. >>>>>> >>>>>> IMO we should have both the options in our connectors. >>>>>> >>>>>> [1] >>>>>> https://blogs.msdn.microsoft.com/exchangedev/2014/06/05/managing-user-consent-for-applications-using-office-365-apis/ >>>>>> [2] >>>>>> https://msdn.microsoft.com/en-us/office/office365/howto/common-app-authentication-tasks >>>>>> [3] https://msdn.microsoft.com/en-us/library/office/dn707383.aspx >>>>>> >>>>>> On Thu, Mar 17, 2016 at 1:00 AM, Vivekananthan Sivanayagam < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I am going to implement a connector for Microsoft office Outllook >>>>>>> Mail, for that I did a research on authentication part first and I have >>>>>>> shared below what I understood during the initial research. >>>>>>> >>>>>>> The Office 365 API[1] services use Azure Active Directory (Azure AD) >>>>>>> to provide secure authentication to users' Office 365 data. To access >>>>>>> the >>>>>>> Office 365 APIs, we need to register our app with Azure AD[2]. At run >>>>>>> time, >>>>>>> created app can continue to use Azure AD and OAuth to authenticate >>>>>>> application requests[3]. >>>>>>> >>>>>>> Authorization Code Grant Flow Diagram >>>>>>> >>>>>>> [image: Inline image 1] >>>>>>> >>>>>>> 1. The client application starts the flow by redirecting the >>>>>>> user agent to the Azure AD authorization endpoint. The user >>>>>>> authenticates >>>>>>> and consents, if consent is required. >>>>>>> 2. The Azure AD authorization endpoint redirects the user agent >>>>>>> back to the client application with an authorization code. The user >>>>>>> agent >>>>>>> returns authorization code to the client application’s redirect URI. >>>>>>> 3. The client application requests an access token from the >>>>>>> Azure AD token issuance endpoint. It presents the authorization code >>>>>>> to >>>>>>> prove that the user has consented. >>>>>>> 4. The Azure AD token issuance endpoint returns an access token >>>>>>> and a refresh token. The refresh token can be used to request >>>>>>> additional >>>>>>> access tokens. >>>>>>> 5. The client application uses the access token to authenticate >>>>>>> to the Web API. >>>>>>> 6. After authenticating the client application, the web API >>>>>>> returns the requested data [4]. >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> https://msdn.microsoft.com/en-us/office/office365/howto/rest-api-overview >>>>>>> <https://msdn.microsoft.com/en-us/office/office365/howto/rest-api-overview> >>>>>>> [2] >>>>>>> https://azure.microsoft.com/en-us/documentation/articles/active-directory-integrating-applications/#BKMK_Native >>>>>>> [3] https://msdn.microsoft.com/en-us/library/azure/dn645543.aspx >>>>>>> <https://msdn.microsoft.com/en-us/library/azure/dn645543.aspx> >>>>>>> [4] https://www.youtube.com/watch?v=TjuJE7Zc1Qk >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Thank youVivekananthan Sivanayagam* >>>>>>> >>>>>>> *Associate Software Engineer | WSO2* >>>>>>> >>>>>>> *E:[email protected] <e%[email protected]>* >>>>>>> *M:+94752786138 <%2B94752786138>* >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Malaka Silva >>>>>> Senior Tech Lead >>>>>> M: +94 777 219 791 >>>>>> Tel : 94 11 214 5345 >>>>>> Fax :94 11 2145300 >>>>>> Skype : malaka.sampath.silva >>>>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >>>>>> Blog : http://mrmalakasilva.blogspot.com/ >>>>>> >>>>>> WSO2, Inc. >>>>>> lean . enterprise . middleware >>>>>> http://www.wso2.com/ >>>>>> http://www.wso2.com/about/team/malaka-silva/ >>>>>> <http://wso2.com/about/team/malaka-silva/> >>>>>> https://store.wso2.com/store/ >>>>>> >>>>>> Save a tree -Conserve nature & Save the world for your future. Print >>>>>> this email only if it is absolutely necessary. >>>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> >> Best Regards, >> >> Malaka Silva >> Senior Tech Lead >> M: +94 777 219 791 >> Tel : 94 11 214 5345 >> Fax :94 11 2145300 >> Skype : malaka.sampath.silva >> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >> Blog : http://mrmalakasilva.blogspot.com/ >> >> WSO2, Inc. >> lean . enterprise . middleware >> http://www.wso2.com/ >> http://www.wso2.com/about/team/malaka-silva/ >> <http://wso2.com/about/team/malaka-silva/> >> https://store.wso2.com/store/ >> >> Save a tree -Conserve nature & Save the world for your future. Print this >> email only if it is absolutely necessary. >> > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
