skip to Main Content

I have a mobile application built upon Ionic Framework which uses many Cordova packages. We are upgrading the app from Ionic3 to Ionic5. In the Ionic3 application our .NET API was responsible to managing user logins. Going forward, in the Ionic5 app we will NOT be managing user credentials – we will be using 3rd party Identity Providers such as Google, Facebook, and Twitter.

We have implemented the Cordova packages to handle external authentication with Facebook and Google and it works fine. How do we tie the token that is received from Google/Facebook to our .NET API? When we try to use the token provided from Google/Facebook we – of course – get a 401 because our .NET API doesn’t know about that token as it was issued from an external source.

I am aware of the process of how to enable the schema described here (External Authentication Services w/ASP.NET Web Api) but in this case the user agent browses to the Web Application in the browser. This is not true in my case as the user agent will be using a mobile application not a web site.
But I hope the principal is the same. But I’m missing something here.

The user will open the mobile app, authenticate with Google/Facebook and be issued a token. Now, what needs to happen to get that token to be recognized by my ASP.NET Web Api?

For example. When I registered my mobile app with Google Developer’s Console I selected that the type of app is an Android application and was issued a Client ID for Android now how can I use this token in my ASP .NET Web API? There MUST be some way to tie the two together or some article out there.

Thanks in advance for your assistance!

Also, I looked at this post and see its 11 years old. Is there something here that I should be doing? Please help point me in the right direction. how-can-i-verify-a-google-authentication-api-access-token

2

Answers


  1. Chosen as BEST ANSWER

    The proper answer is Auth0... see the below sequence diagram!

    enter image description here


  2. It is about data ultimately, and identifying users in a consistent manner, then tracking their history with your app / business.

    SOCIAL LOGIN PACKAGES

    These are often cheap and nasty solutions that add complexity to your apps as you are finding.- especially when you need to look things up by user.

    OPTION 1 – COMPLEX APPS

    Your API could look at the token issuer (ISS claim in the token) and download token signing keys from either Facebook or Google – if JWKS endpoints exist. Then create a user from the access token’s sub claim if required.

    OPTION 2 – SIMPLER APPS

    Deal with only a single type of token in your UIs and APIs, which will work like this. It moves the complexity to your Authorization Server (AS):

    • You have an Authorization Server (use Google maybe) to deal with token issuing and other central OAuth concerns
    • You have multiple Identity Providers (eg Facebook + Google) to support different login methods for users
    • During login Facebook posts a token to the AS
    • Then the AS issues its own token to your UI
    • The AS may be able to use Account Linking to provide a consistent user id regardless of login method

    There is a learning curve in getting this working, but once done it can easily be scaled to many apps with zero code changes.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search