{"id":2466,"date":"2013-10-14T00:42:11","date_gmt":"2013-10-14T07:42:11","guid":{"rendered":"http:\/\/www.cloudidentity.com\/blog\/?p=2466"},"modified":"2013-10-14T00:47:14","modified_gmt":"2013-10-14T07:47:14","slug":"adal-windows-azure-ad-and-multi-resource-refresh-tokens","status":"publish","type":"post","link":"https:\/\/www.cloudidentity.com\/blog\/2013\/10\/14\/adal-windows-azure-ad-and-multi-resource-refresh-tokens\/","title":{"rendered":"ADAL, Windows Azure AD and Multi-Resource Refresh Tokens"},"content":{"rendered":"

After a ~one-week hiatus<\/a>, I am back to cover the new features you can find in ADAL .NET<\/a>.
Today I am going to write about Multi-Resource Refresh Tokens. As I am not a great typist, I am going to abbreviate that in \u201cMRRT\u201d; that does not mean that it\u2019s the official acronym, what I write here is just my personal opinion and does not constitute official guidance, the usual yadda yadda yadda \"Smile\"<\/p>\n

What is a MRRT?<\/h3>\n

Simply put: a MRRT is a refresh token that can be used to obtain an access token for a resource that can be different from the resource for which the MRRT was obtained in the first place<\/em>.<\/p>\n

Let\u2019s unpack that concept with one example. Say that I have two Web API projects, resource1 and resource2, both provisioned in the same Windows Azure AD tenant. Say that I have a native client, also provisioned in the same tenant, with the right entries in the permissions table which allow it to call both Web APIs. <\/p>\n

If I ask for a token for resource1, I\u2019ll go through whatever authentication flow the operation requires, for example getting prompted via browser dialog, if there\u2019s no existing session. After a successful flow I\u2019ll get back an access token AT1 and a refresh token RT1.<\/p>\n

Say that now I want to access resource2. If RT1 is a MRRT, I can simply use RT1 just like I\u2019d use it in the classic refresh flow, but ask for resource2 instead. That will result in getting back an access token AT2 for resource2 (and a RT2 as well) without having to prompt the end user!<\/p>\n

This is exceptionally useful<\/em><\/strong>. To put things in perspective: a MRRT can play for all the resources in a tenant a role similar to the one played by a TGT in Kerberos. Prompts are reduced to their bare minimum, and you can start to think about sessions it terms that are closer to the ones we are used to on-premises, while at the same time maintaining the flexibility and boundaries-crossing capabilities that OAuth2 affords. Is your mind blown yet? \"Smile\"<\/p>\n

Let\u2019 See Some Code<\/h3>\n

This is not just some theoretical mumbo jumbo: you can experience this in your code today (though the endpoint used in the process is still in preview).<\/p>\n

Here there\u2019s some code that defines in ADAL terms the scenario described earlier:<\/p>\n

 \/\/ the tenant<\/span>\r\n string<\/span> authority = \"https:\/\/login.windows.net\/cloudidentity.net\"<\/span>;\r\n\r\n\/\/ the client coordinates<\/span>\r\n string<\/span> clientId = \"a4836f83-0f69-48ed-aa2b-88d0aed69652\"<\/span>;\r\n string<\/span> redirectURI = \"https:\/\/cloudidentity.net\/myWebAPItestclient\"<\/span>;\r\n\r\n\/\/ the IDs of the Web APIs<\/span>\r\n string<\/span> resource1 = \"https:\/\/cloudidentity.net\/WindowsAzureADWebAPITest\"<\/span>;\r\n string<\/span> resource2 = \"https:\/\/cloudidentity.net\/cisNAPAoidc1\"<\/span>;\r\n\r\n \/\/ the AuthenticationContext representing the tenant in your code<\/span>\r\n AuthenticationContext ac = new<\/span> AuthenticationContext(authority);\r\n<\/pre>\n