How can I authenticate my mobile app(flutter) against social providers while using a flow provided by an IdentityServer4 system?
I'm trying to build a mobile app which will authenticate a user via Azure AD b2c. This question will be valid for any provider of an IdentityServer4 service though. For mobile apps, everything I read suggests using the Resource Owner Password Credentials(ROPC) flow. My understanding is that ROPC does not allow for social providers to be authenticated with. Is there an alternative flow to use specifically for social providers authentication? Is my understanding of ROPC wrong? I know mobile apps can authenticate with social providers, I've seen enough do it.
If you want to authenticate social providers and the users of mobile application, you could use auth code flow via Azure AD B2C. You can use it for authentication and authorization in most application types, including web applications and natively installed applications.
About Resource Owner Password Credentials (ROPC) flow, more secure alternatives are available and recommended. This flow requires a very high degree of trust in the application, and carries risks which are not present in other flows. You should only use this flow when other more secure flows can't be used. It is not recommended.
Update:
How does the auth code flow work for mobile authentication when it needs a redirect uri to send the resulting token to? This seems similar to the implicit flow for websites.
They are similar, but they apply different application types. You could learn more about the flow(auth code flow, implact flow). The docs are about AzureAD, but the processes are the same as B2C.
The protocol diagram of auth code flow is this:
The protocol diagram of implicit flow is this:
Related
We have in my organization an existing ASP.NET web application built in a SAAS model that our customers (users from different organizations) login through username/password authentication method. Users' credentials are hashed and stored in our database. We are currently working on adding a SSO feature to our application that would allow end-users from certain organizations to login with SSO using their own Identity Provider (Azure AD, Google, Okta, etc.) to perform the user authentication. We are using the OpenId Connect protocol to establish the SSO connection with IdP, and more specifically the Open Web Interface for .NET (OWIN) middleware. We have implemented the following:
Our SAAS application offers customers the ability to opt for SSO authentication through a setting. End-users from these organizations will be authenticating to our application via SSO AND using their own IdP
Our application supports SSO connection from different IdPs (Azure AD, Google, Okta, etc.)
Our application stores SSO connection settings for each customer that opt for SSO authentication (Client Id, Authority, Secret, etc.). All these settings are configurable in our application, they're available upon registration of the application on IdP side.
My question is about the app registration. I know that in order for our application to communicate with IdP and initiate SSO authentication it needs to be registered on related IdP, so that it can create a trust relationship. I am wondering which party should be responsible of the app registration:
My organization owner of the SAAS application? or
Our customers willing to use SSO authentication method?
With option 1, my organization will have to have an "account" on each of the IdPs our customers use for authentication (I feel this is not ideal for us), register our application and have a mechanism to invite our customers IdP to connect to the registered app.
I feel like option 2 would be the best approach for us as we won't have to deal with app registration, as customers will be responsible of registering the application on their own IdP. From my organization end we will just need to deal with SSO connection settings (Client Id, and other...) which will be provided to us by our customers upon app registration. I wanted to check if this is a common situation that some have already experienced, and what would be the best/recommended approach to go with. Thanks.
I am expecting app registration to be performed on customers side.
I would usually recommend that your internal services and APIs only need to trust tokens from one Identity Provider, and in your case you have one openid connect provider inhouse. That then supports your users to authenticate to and optionally authenticate using an external provider, like how the image below tries to show:
In my experience, having your applications trust and handle tokens from multiple sources will be a pain, as many of the external tokens might look slightly different.
I'm part of a small team as a nodeJS dev and I've been tasked into researching how this can be accomplished. I'm fairly new to OAuth and authentication so please bear with me.
Currently we have a next.js webapp that uses NextAuth for authentication with the user store in DynamoDB. What we want to do is provide an Oauth2 flow so a user can consent to a 3rd party service having access to their profile information via an endpoint. In this case we are the resource server, the 3rd party is the "client" and our user is the resource owner.
The piece of the puzzle I'm trying to put together is how does Auth0 work with NextAuth in this scenario? I want Auth0 to check if the user is logged in (otherwise prompting them to do so) via NextAuth, and for NextAuth to say "this is fine" and then for Auth0 to issue a token to the 3rd party (concluding a "normal" OAuth flow). Is this were SAML comes into play? I see there's a software package called SAML Jackson (lol) and there's a Next-auth integration for it.
Most examples I see usually work the other way around, with Auth0 as the identity provider, and what we're doing may be unique. Sorry if this question comes across as abstract but that's how it exists in my mind currently. Any help understanding this would be greatly appreciated.
You can connect your user store to Auth0 as a custom database connection. And then create an application inside Auth0 and enable the DB connection for the app. This way Auth0 acts as the Authorization server for your client app.
NextAuth.js is just an authentication library that supports the OAuth2.0/OpenID protocols. The role of NextAuth is simply to initiate the authentication flow, take the user to the Identity Provider (in this case Auth0 backed by a custom user store) and finally process the authorization response from Auth0. The authorization response (code) is received at the application end and then exchanged for access_token and user profile (all handled by NextAuth.js).
And for your query on SAML, it's a standard for exchanging identity information between two parties an Identity Provider (IdP) and a service provider (SP). The same is achieved by its more modern counterparts OAuth2.0/OpenID Connect. Typically third-party apps which are deployed in an enterprise setting use SAML to integrate with on-premise Identity Management Systems like ActiveDirectory. You can read more about SAML on https://boxyhq.com/blog/understanding-saml-sso-the-basics-from-the-user-side.
My company distributes an application with a background service component that sends and receives mail from a single email account using SMTP/POP3.
The app uses basic authentication, but we need to implement OAuth 2.0 now due to Microsoft's planned rollback of basic auth for POP3 (and likely SMTP in the future). We have been investigating the account setup and API permissions necessary to achieve this in Azure AD.
Our current understanding is that it is possible to implement the 2-legged client credentials flow by getting an access token and then sending requests to the Graph API (eg. https://graph.microsoft.com/Mail.ReadWrite). However, our application is built to send and receive with the legacy SMTP/POP3 protocols and changing the mail features to send HTTP requests to the Microsoft API endpoints requires a partial redesign.
It appears that only 3-legged flows are supported for the legacy SMTP and POP protocols. These permissions are only available as "delegated permissions" on the Graph API. There are no equivalent "application permissions" that would allow us to use these protocols from our background service without a user present to do the initial authentication.
Integrating a browser redirect into the app for the initial authentication also requires a significant update to the application. The app is 14 years old and the original programmer is no longer at the company. Due to that fact as well as limited resources, we're hoping for a solution that doesn't involve implementing browser integration or major changes to the sending and receiving functions.
Is it possible to implement a 2-legged OAuth flow to authenticate an account for sending and receiving over SMTP/POP3?
Might any of our assumptions be incorrect?
No. It's impossible.
OAuth access to IMAP, POP, SMTP AUTH protocols via OAuth2 client credentials grant flow is not supported.
Currently the supported flows are:
OAuth2 authorization code flow
OAuth2 Device authorization grant flow
See details here.
If you have this requirement, you can post your idea on Microsoft Graph user voice.
I'm building a mobile application interacting with backend providing REST APIs. Most of the APIs are protected by access_token provided to a success login.
However I'm curious that WHO will protect the signup, login APIs from anonymous callers, as those APIs don't require access_token (assuming that the system handle DDOS well)? Using API Gateway like Kong with its OAuth to protect all APIs seems to be proper solution but somehow a bit overkill for small/medium/no-micro-service projects.
Some of my simple ideas is to use a set of predefined username-password pairs for Basic auth or more complicated one like Digest auth or an OAuth layer putted before API routes. Mobile app keep those secrets then use them to make signup, login API requests.
Do we any other solutions here?
Mobile app keep those secrets then use them to make signup, login API requests.
Please do not put any secret at all in your Mobile App once they can be easily reverse engineered with frameworks like Xposed.
Mobile Apps can be made more secure and difficult to reverse engineer by using some techniques to secure the secrets both in the Mobile APP and in the API server, like:
Certificate Pinning to protect the communication channel between the Mobile App and the API.
HMAC signed/encrypted messages.
Signed JWT Tokens with encrypted content.
OAUTH2 as a more secure alternative for authenticate your users.
Advanced code obfuscation techniques in the Mobile App code.
You can read more about how some of this techniques can be used and bypassed on this article.
However I'm curious that WHO will protect the signup, login APIs from anonymous callers
If you have read the article I linked above, about Mobile API techniques, you are aware that you need to protect all API endpoints, even the ones behind the authentication, otherwise you will be subject to API abuse of your endpoints by automated scripts, bots, crawlers and all kind of attackers that may profit from your service or data.
For hardening the security between your Mobile App and the API server you should use a Mobile App Attestation service, that will guarantee at run-time that your App was not tampered or is not running in a rooted device by using an SDK integrated in you App and an attestation service running in the cloud, that will emit a signed JWT token that then the API server can validate to distinguish a valid request from a fake one.
JWT Token
Token Based Authentication
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.
Certificate Pinning
Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.
OAUTH2
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf. This
specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849.
Im trying to build an OAuth 2 provider and for the web server flow its very strait forward but i cant figure out the best way to implement an installed application flow
most examples ive seen follow essentially the web server flow within an embedded browser in the mobile application, this is also generally how facebook and google demonstrate 3rd party apps to use their APIs
but do facebook and googles own mobile applications actually use that flow or is there some better way to implement mobile authentication
my main problem stems mostly from the client id and client secret, if its embedded in every installed version of a mobile app it becomes essentially useless as it can be easily sniffed, and there's no clear oauth 2 examples of having a per application basis for the client secret
so whats the best way of securing my own mobile app using oauth 2
As you probably want to have user-based authorization and do not want to deal with a username/password on client side, this leaves you the choice to using the Implicit Grant flow or the Authorization Code Grant flow (what you call web server flow).
Now check out the OAuth 2 specification's Installed Applications section. There they state:
When choosing between the implicit grant type and the authorization code grant type, the following should be considered:
Native applications that use the authorization code grant type SHOULD do so without using client credentials, due to the native application's inability to keep client credentials confidential.
When using the implicit grant type flow, a refresh token is not returned, which requires repeating the authorization process once the access token expires.
Whether to use an embedded or an external user-agent is also widely covered by the specification.
For implementing this securely (at least as far as this is technically possible on an open platform), search the specification for the word native and read the sections containing that word multiple times, especially the Client Authentication and Client Impersonation sections.