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* 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. >>> >> >> >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
