I am using the ADAL3 for authenticating on the Azure AD app. Then I use the AuthenticatedClient Async for logging into the Azure backend.
What is the correct strategy for consuming Azure backend and working with token? Do you call AuthenticateClientAsync before each call to the backend to be sure that if the session expires on the backend the token will be used to start the session automatically? What append if the memory save token is expired, do you manually ask users to login again?
Someone has a sample of an app that popup a login page then call some service and popup a new login page if needed?
Thanks for your help.
According to your description, I assumed that Azure Mobile Apps would be the approach for you to work as your mobile backend. And you could authenticate your customers with AAD and leverage the client SDKs provided by Azure Mobile Apps to communicate with your azure mobile app backend.
I would recommend you follow this tutorial for creating your Azure Mobile App and download the sample project for getting started. Then, you could configure your mobile app to use AAD login, details you could follow here. Moreover, more details about how to use the client SDKs for Azure Mobile Apps in your xamarin project you could follow here.
Someone has a sample of an app that popup a login page then call some service and popup a new login page if needed?
After logged via MobileServiceClient.LoginAsync, you would retrieve a JWT token issued by your mobile app backend and you could get it by accessing MobileServiceClient.CurrentUser.MobileServiceAuthenticationToken. And you could cache the token for reusing it. You could wrap the operations against your mobile app backend and catch the exception when the token is expired and manually call LoginAsync to ask the user for logging again or validate the token in your client side and re-login if the token is invalid before you send requests to your mobile app backend. For caching the token and validate the token, you could follow adrian hall's book about Caching Tokens. For wrapping the table operations, you could follow here.
Related
I've got a mobile app that uses a native oauth flow via react-native-oauth (which makes use of an inAppBrowser) to complete the oath flow for ios. When it's complete, I have the tokens and idToken natively.
What I'd like to do now is to pass these to my backend web server, so that I can kick start some calendar sync process for this user. However, my backend is using MSAL.NET with a custom TokenCache, so expects the tokens to be present in this cache. To achieve this on the web app, there is an oauth flow baked into the web app that is hooked into this MSAL setup, and thus works:
// Hook the auth code up to the token cache, that will ensure it gets into the database (msal_token_cache)
TokenCache cache = new MsaldbTokenCache(userId, db).GetMsalCacheInstance();
ConfidentialClientApplication cca = new ConfidentialClientApplication(opts.ClientId,
settings.Core.BaseUrl.UrlCombine(redirectUrl),
new ClientCredential(opts.ClientSecret),
cache,
null);
AuthenticationResult result =
await cca.AcquireTokenByAuthorizationCodeAsync(code, new[] {"Calendars.ReadWrite"});
I've no idea how to do this with my ios-authed tokens. I can't allow the web server to acquire the tokens via auth code exchange since it was initiated in IOS...
Can anyone help?
I would design the solution to be architecturally separated so that it supports both web and mobile, which should work fine as long as both clients use the correct scopes for OAuth redirects:
A Rest API triggers the calendar sync process for the user received in the access token
One client of the Rest API is the back end of a web app - which uses MSAL.Net - and perhaps issues cookies to the browser
Another client of the Rest API is the mobile app - which uses React Native OAuth
I would avoid aiming to mix the 2 clients together though. If the web back end requires auth cookies then the mobile client will not be able to provide them.
The back end for the mobile app needs to a Rest API endpoint and it's possible that the existing back end may need to be refactored a little, to separate web client concerns from API concerns.
Could you please provide me an example or description how to return an access token to the mobile application with facebook login.
Here is the workflow that I want to achieve:
Mobile user registers via Facebook
User is registered on the server database after successful Facebook login
OpenIdDict Access Token is returned from server to the mobile application
I have already implemented local user password workflow but cannot find any example of Facebook login via mobile app.
The flow you describe is known as the "assertion grant". Read this other SO thread for more information about how to implement it with OpenIddict.
I have an API proxy that do the rest of my business login, identityserver for authorization and Android Client.
I using implicit flow with the android client.
I request an access token from idsrv then make a request including this token to contact with the api and every things works correctly.
Now i want an API or any way to register new user instead of the default web page so i can use this APIs to create new users from my proxy or from my android app.
What is the better way to do that?
This is, by design, out of the scope of IdentityServer. You can build your own API that can update the user database for user provisioning.
Scenario:
I work on a portal application that has its own user credential store. Another company who has a mobile app needs to authenticate against our data store using SAML 2.0.
The user will launch the mobile app, it will send an authentication request to the portal/IdP, the portal presents login page, user logs in and a SAML response is then sent back so user can continue using mobile app.
My question: Is there anything else extra needed if a user clicks a link in the mobile app that requests a protected page on the portal? I mean, the user will be authenticated in the portal already, so it should let them right in without any other kind of token or whatever sent to the portal from the mobile browser - is that right?
Are there any other considerations or resources for referencing a situation like this?
Any assistance is appreciated.
There are two aspects that needs to be considered here: Authentication and Authorization. Even though the user is authenticated, s/he might not be authorized (i.e. have permissions) to access that particular link.
If you follow SAML 2.0 protocol that is OK.
You have just to be careful what are you sending with AuthetnicationResponse and how it will be used on mobile app.
There is not extra tokens. AuthenticationResponse (encrypted and signed) is token by itself.
I am developing a web ap with firebase and I want to connect it directly from the frontend using JS so I avoid to have a middle layer. So my question is basically how can I do a secure implementation with firebase and how can I hide the credentials that will be exposed on Javascript
You never store credentials on the client. See this overview for a quick summary of how security works in Firebase: https://www.firebase.com/docs/security-quickstart.html
If you don't want to run your own server to do authentication, you can use the Firebase Simple Login service. Simple Login integrates with Facebook, Github, Twitter and Persona to provide user login. You can learn more about the service and how to use it here: https://www.firebase.com/docs/security/simple-login-overview.html