Home/ Questions/Q 8199177
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T06:07:05+00:00

What is the point of using OAuth 2.0 client-side authorization in Android if built-in

  • 0

What is the point of using OAuth 2.0 client-side authorization in Android if built-in WebView browser doesn’t have access to cookies of default user browser? I mean, if I open some oauth-url (e.g. http://blablabla.com/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=token) in WebView – the user will anyway be prompted to enter his credentials to sign in to “blablabla.com” social network. Because even if he is already signed in with some of his browsers (Opera or Dolphin, or default browser), the WebView browser doesn’t know anything about corresponding cookies.

EDIT:

I’ll try to make it a bit clearer.

The main goal is to simplify sign-in procedure in my application. I’d like to implement such mechanism that we can see on many web-sites: “Login with… Facebook/Google/Twitter/whatever”. And in desktop browser that approach works perfectly, because the end-user is already signed in to aimed service WITHIN THIS BROWSER. So basically to sign-in in to my site all he needs is:

  1. Press button “Sign in with…”
  2. On redirected window/popup press
    “Approve/Confirm”.
  3. Get redirected back, already being signed-in.

The main benefit is that user doesn’t need to enter his email/name/whatever – I’ve already extracted it from his social-network account.

And I’m wondering how to get same effect on Android. The problem is that, as I can see, we can’t let user avoid entering password, because the application (WebView) never knows if he is signed-in to some outer service or not. That’s why user anyway will be prompted to enter some of his details and all of OAuth benefits become annihilated.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The workaround depends on what you are trying to do. It’s not clear to me, looking at your question again, because you do not explain your use case. Instead you are indirectly asking for something that looks very broad as if you want to maintain an Android system-wide login state that spans over multiple applications using shared cookies.

    Due to security reasons that is neither good nor wanted. A rogue app could do whatever it wants to do with existing access tokens requested by other apps or just temper with or read existing cookies created and maintained in other apps.

    Assuming you are trying to authorize your own app access to a web service using OAuth 2.0 by letting the user log in with a WebView, you need to implement your own WebViewClient, override its onPageStarted or onPageFinished method and check whether the URL argument matches your redirect URL.

    If there is a match you need to extract the access token from the URL string. If there is also a refresh token available, then extract that one, too.

    (This however only works for a certain type of OAuth flow, which adds the access token to the redirect URL.)

    Now you have at least an access token available. Store that token in the private preferences of your application and use it in your service requests until you get a 401 not authorized error message back from the service. At that point you can use the refresh token if available to request a new access token or you have to show the login WebView again.

    If you are trying to access a Google service from your app you may find the article Getting started with the Tasks API and OAuth 2.0 useful.

    • 0