{"id":3302,"date":"2015-08-13T00:28:35","date_gmt":"2015-08-13T07:28:35","guid":{"rendered":"http:\/\/www.cloudidentity.com\/blog\/?p=3302"},"modified":"2015-08-13T00:29:24","modified_gmt":"2015-08-13T07:29:24","slug":"adal-3-didnt-return-refresh-tokens-for-5-months-and-nobody-noticed","status":"publish","type":"post","link":"https:\/\/www.cloudidentity.com\/blog\/2015\/08\/13\/adal-3-didnt-return-refresh-tokens-for-5-months-and-nobody-noticed\/","title":{"rendered":"ADAL 3 didn’t return refresh tokens for ~5 months… and nobody noticed"},"content":{"rendered":"

\"JohnOliver1150070\"<\/a><\/p>\n

As you know, ADAL is not meant to be a protocol library. You tell us about your client app and the resource you want to access; we get the proper tokens for you from Azure AD, via few simple primitives and without burdening with nitty-gritty protocol details.<\/p>\n

That said\u2026 that arrangement is not 100% air tight. We do occasionally leak the abstraction: for example, we use OAuth specific terminology here and there (redirect uri\u2026); we accept protocol parameters in extraqueryparameters<\/span>; and so on. When we do so, we like to think it\u2019s never an oversight, but a deliberate decision. We usually weigh whether the convenience of providing access to lower level constructs outperforms the complexity we\u2019d burden you with for preserving a fa\u00e7ade\u2026 if the convenience comes out a winner, we go for it: after all ADAL is not a science experiment, it\u2019s something meant to make your life easier.<\/p>\n

The refresh token in the AuthenticationResults<\/span> , and corresponding AcquireTokenByRefreshToken<\/span> method, is one such violation. You don\u2019t really ever need to use the refresh token from your own app code, given that ADAL caches and will automagically use it whenever you call AcquireToken<\/span> and the requested token need renewing. Ssee this<\/a> and this<\/a> for details. In ADAL v1 that wasn\u2019t strictly true, given that the cache was specialized for native clients and not really suited for server side use: we had to provide you with the refresh token bits – so that you could do your own arrangements on web sites code-behind or any scenario other that the supported native client case. In ADAL v2 we improved the caching infrastructure<\/a> to support server side scenarios, extending ADAL\u2019s automatic and transparent use of the refresh token to all the mid tier flows (or, if you want me to leak protocol details\u2026 for all confidential client grants). However we weren\u2019t completely certain that this would have addressed ALL possible scenarios, so we decided to keep exposing the refresh token in our object model.<\/p>\n

That\u2019s when we started noticing odd things. Developers with little or no protocol knowledge, the vast majority, happily relied on ADAL to do all the session management on their behalf and blissfully enjoyed all the automatic refresh token usage I described. So did all the people who used our GitHub samples<\/a> or the VS templates as starting point for their own apps. However some developers, typically the ones with some existing protocol knowledge, skipped the samples altogether and attempted to use the library only \u201cby intellisense\u201d: knowing that OAuth2 does use refresh tokens, assuming that ADAL uses OAuth2 and finding methods accepting refresh tokens made them conclude that responsibility of storing and using refresh tokens was on their app code. That led to tons of extra work, code structure far more complicated than necessary, security issues and reduced functionality \u2013 for example, not all of those devs knew what a MRRT<\/a> is.<\/p>\n

Thankfully the number of the developers falling in that trap was very small in comparison to the total ADAL usage, but that made us think \u2013 do we really<\/em> need to keep returning the refresh token and accept it in AcquireToken? We combed through mail threads, forum posts and customer docs searching for scenarios that could not be addressed by ADAL\u2019s automatic usage of the refresh token \u2013 and found none. On April the 22nd we built a NuGet for ADAL v3.x with all signs of refresh tokens removed from ADAL\u2019s programming surface<\/u><\/strong>, then pushed it out on NuGet.org.<\/p>\n

Five months later, things seem to be going still pretty well. It is not entirely true that absolutely<\/em> nobody noticed \u2013 but the couple of people who did, turned out to be perfectly well served by ADAL\u2019s automatic use of cached refresh tokens.<\/p>\n

Per the above, at this point we are reasonably confident that we can ship ADAL 3.x without leaking refresh tokens \u2013 and that\u2019s good, because the moment of shipping is getting closer and closer (nope, I can\u2019t share the exact date yet \u2013 sorry!).<\/p>\n

That said, it is always possible that we missed some important scenario. That\u2019s where YOU come into play. If you are using ADAL v2 and you are relying directly on refresh tokens bits anywhere in your code, please get in touch with us \u2013 we would like to understand whether this means we need to bring refresh tokens back after all, and if there is a way of achieving the functionality we need using ADAL cache\u2026 we would love the opportunity to show you how.<\/p>\n

Thanks in advance for all your feedback, and happy coding!<\/p>\n","protected":false},"excerpt":{"rendered":"

As you know, ADAL is not meant to be a protocol library. You tell us about your client app and the resource you want to access; we get the proper tokens for you from Azure AD, via few simple primitives and without burdening with nitty-gritty protocol details. That said\u2026 that arrangement is not…<\/p>\n","protected":false},"author":1,"featured_media":3301,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3302","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/3302","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/comments?post=3302"}],"version-history":[{"count":2,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/3302\/revisions"}],"predecessor-version":[{"id":3304,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/3302\/revisions\/3304"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media\/3301"}],"wp:attachment":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media?parent=3302"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/categories?post=3302"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/tags?post=3302"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}