Every smartphone user is familiar with the following scenario:

Login via smartphone browser

  • You install an app from your respective app store.
  • Before actual using the app, you have at least to log in.
  • When clicking on the login button, you are getting redirected to a web login page
  • When your login has been successful, you are getting  back to your app and start using it

But how to achieve this is as an Android developer? Do I need a broad knowledge how to setup a secure infrastructure?

When I start to introduce an authentication and authorization mechanism workflow, I definitely do not implement everything from scratch. Configuring all this stuff can be a real pain in the neck. Moreover, the probability is quite high that crucial security bugs occur.

Therefore, I reused a toolchain consisting of AppAuth for Android and Identithy Server 3 as authorization server in my last project.

AppAuth for Android

AppAuth is a powerful library communicating with OAuth 2.0 and OpenID Connect providers. All the forwarding and redirecting magic from app to browser, and vice versa, works already out of the box. That saves a lot of time and offers less working points to make any crucial security mistakes, excellent!

Embedding the dependency

While we were configuring AppAuth last summer, the latest version was 0.3.0. In the meanwhile, it is 0.5.1.

AndroidManifest.xml Configuration

First of all, define an intent filter in the activity where you intent to perform the authorization request to the authorization server.

I recommend to pull the action name out to a string resource value. The name will be reused to perform authorization and access token requests in the upcoming sections.

RedirectUriReceiverActivity

Furthermore, it is required to define a redirect URI Activity. This redirect URI Activity is an invisible activity getting invoked in case of a successful (browser) login. Roughly speaking, it handles the redirection from the browser to the app and returns back the received authorization server response.

Actually, it is possible to define the AppAuth class “net.openid.appauth.RedirectUriReceiverActivity” as RedirectUriReceiverActivity. When I worked with OpenID’s hybrid flow , I had to conduct some minor changes.

An authorization server returns a redirect URI containing all relevant token parameters for the client. AppAuth always tries to resolve the given token parameters as URI query string. However, when hybrid flow has been specified as authorization code flow, Identity Server returns the tokens separated by a hash fragment spec-compliant to the OpenID standard.

Therefore, the AppAuth RedirectUriReceiverActivity has to be extended. A possible workaround could look like this:

After that, we can define a working RedirectUriReceiverActivity compatible with AppAuth for Android 0.3.0.

Authorization Request

Triggering the call is not a rocket science. Of course you have to know your Identity Server’s

  • Authorization endpoint, token endpoint, response types and scope.
  • The client id that has been defined for your client.
  • The redirect URI to resolve the browser’s authorization response to the calling app.
  • The authorization action has to be set accordingly to the defined intent filter value.

Token Request

Briefly worded, in OpenID Connect the authorization request is the first step to receive an authorization  code via a “user-agent”. In our case, the user-agent is the “browser” sending our login data to the authorization server.

The app is now capable of exchanging an authorization code for an access token from the Identity Server. Via this access token, the client is allowed to access the services of your backend infrastructure.

The same mechanism can also be used to refresh an access token.

Generally, shared preferences should be used to persist and read the access token. Thereby, it can easily be reused in your HTTP authorization header.

That is the way to show your services your admission ticket.

Btw: I used Android Annotations to access my shared preferences.

Identity Server 3

Nevertheless, the perfect Android client setup is useless if your authorization server does not speak the same language as the app does.

It is quite straightforward to configure an Android client definition for Identity Server 3.

Did you recognise the client id, secret and redirect URIs? There are the same as defined in our Android client.

Despite of some weak points, a common way to provide a proper authentication and authorization mechanism for mobile clients is the proven hybrid with proof key flow of OpenID Connect.

Conclusion

Finally, this was a short walkthrough how to configure your Android app with AppAuth and Identity Server 3 as authorization server.

Check out the attached references for further background information!

Cheers,

Stefan

References

AppAuth for Android

OpenID Connect

Identity Server

Leave a Comment

3 comments

  1. “Due to the fact that Identity Server 3 does not agree with the URL standard using “?” for query parameters, the RedirectUriReceiverActivity has to be customized. Identity Server 3 is using “#” as separator instead.”

    That sentence is wrong – IdentityServer behaves spec-compliant (and is also official certified by the OpenID Foundation). Tokens must be sent after a hash fragment in hybrid flow.

    https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthResponse

    Please update the post.

  2. S

    Hello Dominick,

    thx for the clarification! Great to know that AppAuth is the actual bad guy.

    The post has been updated.

    Kind regards,
    Stefan

  3. No-one is the bad guy. AppAuth assumes code flow – not hybrid. That’s all.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close