My suggestion:
Describe again exactly the steps and show us the library, apps (?) and code for it. Right now we only know you are somehow authenticating with Azure and saving the access_token, but not what is involved here and actually happens.
Best would be a simple repro repo on Github that we can look at that shows the actual problem or implementation.
That’s what I needed.
Thank you! That reduces the list of places I need to worry about and research into. Now I can concentrate solely on Azure side.
Highly appreciated! 
I think your problem is not with one specific code line or function, but with the general concept of what is happening here. In my opinion the probability is very high that you are looking into stuff that it absolutely irrelevant. Explaining what exactly is happening might help us help you to avoid that.
I have to say after reading this issue and this issue I would have to say my impression of the current state of cordova/ionic support for this entire Azure Mobile platform would be somewhere between “broken” and “dismal”. I would recommend investigating alternative OAuth solutions.
UPDATE: Lest it be thought that I’m just throwing shade without suggesting alternatives, I think cordova-plugin-safariviewcontroller looks like a promising replacement for IAB when doing OAuth stuff.
Silly question, but did OP say anywhere that he is actually using this library?
Wow! Lots of questions.
I will try to answer/reply to all of them next. My apologies before hand if my replies offend anybody in any way. That is not my intention. All I am trying to do is understand the framework and its working better.
@AaronSterling - If this is true then there must be a way to access that browser on the device through my Ionic App. If there is then my question was exactly about it, how do I access it. Please do let me know if you know how to do it.
@Sujan12 - The “Azure Mobile App” is not an app. It’s the name of a product/service that Azure Cloud provides which can be used to implement the back-end/server-side piece of a mobile app. The terminology threw you off there.
I will try to describe it and put the snippet of code that does it.
So, using the library for Azure Mobile App, you can connect to a Azure Mobile App you have created in your Azure Cloud account. Using this connection, you can make a authentication call and specify you want to get authenticated with Azure Active Directory (AAD). And for your Azure Mobile App on cloud to know what AAD to connect to you configure in your Cloud AD which Azure Mobile App (any App Service for that matter) is going to be connected for authentication and upon successful authentication where to take the user to…in a nutshell. I have done all this in my cloud account and have written the corresponding code in my Ionic App to get the job done, following is the code in my Ionic App:
Here is the relevant code in my AuthService.
The libraries I am using are:
I was not talking about ionic/storage. I wanted to know where does Ionic Framework or the device store a received authentication token.
Not sure, why you think this is not relevant. The Ionic App does run in a browser so Cookies are definitely possible. So, instead of relevance, not trying to be rude, it would help if you could answer the simple question.
I am not sure if I understood it completely. But my Ionic app is certainly not calling something outside. It only calls the Azure Mobile App or other App Services in my Cloud account for all server-side calls. If you are referring to that then I already mentioned it in my immediate next sentence in the same post (i.e. …unless you are explicitly invoking something using that service from the app (like authorization, logout, etc.).)
I shared the Plunker above but here it is again.
I have explained everything that is there and have also provided the code. That’s exactly what there is to do it.
I am indeed using the same library. The one I use (cordova-plugin-ms-azure-mobile-apps) is a wrapper around what @rapropos is pointing to (azure-mobile-apps-js-client) in his comments. That’s what Azure Mobile App support told me some time back.
Phew!
@rapropos - I need to reply to your comments separately. Will do that in a few…
That is not true in general, and browser companies are moving in the direction of restricting what apps can do, not allowing more permissions. Maybe there’s a way to do it through the Azure API, but if the issues are severe, that might not be possible either.
Overall, you seem to believe a lot of things without evidence. I think you would benefit from taking a step back from “app programming” and spend some time learning about how modern browsers work
@rapropos - I am indeed using InAppBrowser. However, I do not recollect what I am using it for. Thanks a lot for pointing that issue, perhaps that’s what it is. Will investigate further.
Thank you.
Unfortunately too much into Azure Mobile App to back-out, unless it’s a show-stopper. I will try to get some more information from Microsoft support and if they now have a solution.
I will also check cordova-plugin-safariviewcontroller. The term “safari” in there looks like is iOS specific. Maybe there is Android version also.
Thanks again, very much appreciated!
Hmmm…interesting.
Thanks for pointing that out. Can’t afford to take a step back. 
But I can certainly spend time learning. Believe me, I am a good learner.
Can you provide some links on where I can learn about how modern browser work?
Thank you.
It started out that way, but if you check the docs for later versions it uses something similar called “Chrome Custom Tabs” on Android.
Then I would rate it “fairly probable” that its cookie storage is causing what you see.
Ok, lets start with the small stuff:
Ionic and the device only save stuff if you tell them to. They don’t do anything by themselves, magically in the background. That’s a good thing.
The only way relevant here would be Ionic Storage.
Ionic apps don’t call “setCookie”, unless you wrote code to tell it to (although I am not sure that is possible). (This also is not a normal browser, but a webview, so it is in a different context by design) So, if anybody is doing Cookie stuff, it is not Ionic or your app but some library you are using. And before knowing what that is actually using (InAppBrowser? external browser window? Native overlay with its own environment?), it is impossible to tell if Cookies are involved at all.
As I said before, you are deep in investigating stuff (Cookies, magic storage of data) that might not be relevant at all.
Now on to the interesting and relevant things:
Could you provide a link to that “Azure Mobile App” thing you mean?
From my limited readings an “Azure Mobile App” is an entity created in the Azure backend. You use some client SDK to talk to that backend, telling you that you want to talk about a specific app.
So what you refer to as this.cloudMobileApp in your .ts file, is actually a cloudMobileAppClient or mobileAppsClient that is provided by the SDK you are using. Just changing the name of this makes it much clearer what it actually is.
That means you are using these 3 (!) things:
Looking at auth-service.ts, WindowsAzure is from #3, Microsoft (correct: Microsoft.ADAL.Authentication*= is from #1.
#2 is not mentioned in the code at all because you are using #3 directly via import. Do you really want to do that? Looking at the plugin docs, I am not sure this is the way it is intended to be used. This way it is not really clear which one of the both are actually running in your app. the Cordova plugin may do additional things to the plain JS client. This should be cleaned up.
Back to your code. You have these methods in your auth-service:
loginWithAdal
silentLogin
getAuthorizedUser
logoutUser
setAuthorizedUser
Can you explain where each of those (first two are most important) are actually called and why? With this knowledge, we know where to actually look at how the auth process works and find out where these things save their data.
(Are getAuthorizedUser and setAuthorizedUser actually used outside of this service? (Suggestion Make them private or add _ in front of their name to make this more clear))
Could you please also provide an overview of how the LoginPage stuff works in your app? Are you using setRoot etc? How exactly does it find out if to show the LoginPage or not? This is relevant to your initial problem description.
Any progress here? I’m honestly interested on how this turned out.
Good to know, there is interest! 
It is confirmed by Microsoft support that a Cookie gets set in the browser…related to InAppBrowser plugin.
@rapropos was spot on!!
No progress on it though as I am on other priority items. Will definitely post if and when I find a solution.
Discovered today that Chrome & Safari webviews for your Ionic app DO indeed store cookies & tokens from login POST requests. They do so differently, and YES they do so whether or not you explicitly write code to do so.
The answers above stating that Ionic “doesn’t store anything unless you tell it to” are wrong.
I do have the “In-App Browser” installed, but it has nothing to do w/the login page or processes. If it manages to completely take over the behavior or a Cordova app’s containing webview, then that’s a separate large problem …
My Ionic3 app could login just fine once from iOS or Android.
If I logged out, iOS would be able to login again just fine.
Android couldn’t login again w/o entirely deleting & reinstalling the app.
The reason is that it was still trying to use a stored token from a previous login/user. iOS/Safari simply deleted the tokens/cookies and had no problems w/subsequent login.
Clearing cookies manually w/Chrome Inspector got it working properly.
I considered using the Phonegap Cookies plugin but didn’t need to. That plugin’s README explains why usual ‘window.clear…’ methods don’t work. Unclear whether or not it would work w/Ionic/Cordova - I didn’t try it.
In my case, a separate “logout” call to the server worked to clear the cookies invisibly stored in the Ionic app’s browser window. I call that at logout, and also just prior to logging in to be sure the cookies are gone (my users are often offline & the initial logout call might fail). That clears the otherwise invisible/inaccessible cookies, and now Android works just like iOS.