Azure AD Records User Consent for Native Apps in the Refresh Token

An alternative title for this post could have been “Why users of my native app are prompted by Azure AD for consent every time they authenticate?”.
In brief: for native apps, the consent granted by the user is recorded by Azure Active Directory in the refresh token issued on the first successful authentication.
As long as the same refresh token is used (and is not expired, which BTW can take weeks or months), the user won’t be prompted for consent or credentials again.
To stress the point: the consent for native apps/public clients is not persisted anywhere in the cloud (as instead it happens when consenting for a web app/confidential client). If the refresh token is lost or it expires, the user will be prompted again for both credentials and consent.

That said: if you use ADAL, you can happily forget that a refresh token plays a role here – the library takes care of everything for you. More specifically: ADAL caches and uses refresh tokens automatically and transparently every time you call AcquireToken*. As long as you keep calling AcquireToken* every time you need a token, the right behavior should take place.
In Windows Store (tablet and phone) the token cache is automatically persisted for your app, so that it is available across multiple run & shutdown cycles.
In .NET, however, the default is to keep cached tokens in memory – as soon as you close your process, it is gone. If you want to have keep those available across different runs and avoid re-prompting, you have to initialize ADAL with a persistent cache as shown here.

Another frequent issue that leads to extra prompt is the misuse of the common endpoint, see the ADAL section of this post.

I know this post is uncharacteristically brief – but hopefully it will be enough to help you through the obstacle if you landed here while searching for a solution for this issue