learning-layers / android-openid-connect

A sample Android app that communicates with a non-Google OpenID Connect provider.

OpenID Connect Sample for Android

An Android app that communicates with a non-Google OpenID Connect provider.

Please note:
This is currently unmaintained, check out kalemontes/OIDCAndroidLib instead.

Use Google’s own APIs, if you want to connect to their OpenID provider servers. This project is meant to connect to non-Google providers, which those APIs don’t support.

Since OpenID Connect is basically an extension of OAuth 2, it’s convenient to use readily available libraries as the foundation. This is built upon google-oauth-java-client.

Features

• integration with Android’s AccountManager
• support for multiple accounts
• login/authorisation via a WebView
• refreshing tokens when needed
• requesting user information
• making authenticated API calls
• heavily commented code

Usage

You’ll need to register your app with an OIDC provider and put your configuration data into Config.java.

When you launch the app, you’ll see this:

Tapping the button will let you log in to the provider and authorise the app to use your data.

If all goes well:

1. the app gets authorisation
2. the tokens are saved and associated with an account using Android’s AccountManager
3. the button will indicate that you’ve logged in by displaying your username. (Assuming that the provider has set preferred_username.)

You can add more accounts via Android’s settings. When there are multiple accounts, the app will ask you to choose one of them when logging in.

Dependencies

This project depends on the following libraries. They are fetched automatically via Maven. The last three are for convenience and can probably be written out if needed.

• google-oauth-java-client
• google-api-client-gson
• google-api-client-android
• http-request

History

This project was originally made to be included in the Ach So! Learning Layers project.

It was developed by Leo Nikkilä at the Learning Environments research group of Aalto University, Finland.

Legalese

Licensed under the MIT licence. See LICENSING.md.

android-openid-connect's Issues

Convert this into a library

If there is enough interest. Voice your opinion below!

Bad UserInfo request ¿?

When requesting userinfo data I have an error using django-oidc-provider as the OP.

As the spec says using token bearer:

GET /userinfo HTTP/1.1
  Host: server.example.com
  Authorization: Bearer SlAV32hkKG

But this Android client sends the complete id_token, shouldn't be the access token??

(Pdb) self.params.access_token
'eyJhbGciOiJSUzI1NiIsImtpZCI6ImRhZGMyNTdjYjdmY2YxYjg0ZTJiMGE5ZDY2MGJmYzE2In0.eyJhdWQiOiIxMzU3NDk4MSIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODAwMC9vcGVuaWQiLCJleHAiOjE0NDcyNzM2NzIsImF1dGhfdGltZSI6MTQ0NzI3MTY1NCwiaWF0IjoxNDQ3MjczMDcyLCJzdWIiOiJodHRwczovL2lkLmJ1ZW5vc2FpcmVzLmdvYi5hci9vcGVuaWQvanVhbmlmaW9yZW5AZ21haWwuY29tLyJ9.V2ONgH4thr35F2MAw14iQ8EPQCcEosbNW5N_IlhvbUSOqwXrpnQu9504kKOlDHTXPI3eTlj6C1qWVfxrdcVdB1nBBTBgqDQb6n-XwJKnyP4vzeR5VQG91AEQ0r1hEG8Ch8CiZlbmqncxKaOh-0KR_5zWiWgvpse3sNQA0T4NQ5A'

Am I wrong?? Thanks!

Importing into Android Studio, blank project

I am very interested in using your library, but I am having issues importing it into Android Studio. When I import the project in, I cannot see any of the app files. Only the Gradle folder and the root files.

Just by looking at the folder structure I am led to believe that this is an Android Studio project vs Eclipse. Any idea why I am not able to see the project files?

Thanks!

Add support for public clients (Implicit Flow)

Hi, to start let me thank you for posting this sample. It has help me understand and do some implementations of my own to use OIDC on Android. Am looking forward for the lib ;)

I'll just like to point out that, from http://tools.ietf.org/html/rfc6749#section-10.1 we know that :

The authorization server MUST NOT issue client passwords or other
client credentials to native application or user-agent-based
application clients for the purpose of client authentication. The
authorization server MAY issue a client password or other credentials
for a specific installation of a native application client on a
specific device.

So Android Apps must not use Code Flow, instead they should use Implicit Flow. It's ok for testing purposes, but it may be a security issue if used on production as it is (I know you pointed the Dexguard to offuscate) and just adds layers of complexity for, lets say, nothing.

Implicit Flow has it's contraints and limits (i.e. no refresh tokens) but i think it would be interesting for completeness sake to implement this flow.

Am working on it so if i manage to do something clean i'll make a pull request.

Use Hybrid Flow instead of Code Flow

Hi again! Well this is kinda related with #4 in a way. I'll like to help you enrich (if i can) the sample by using Hybrid Flow instead or in addition to the Code Flow.

As the OIDC doc says (http://openid.net/specs/openid-connect-implicit-1_0.html) :

The Authorization Code Flow is intended for Clients that can securely maintain a Client Secret
between themselves and the Authorization Server, whereas the Implicit Flow is intended for 
Clients that cannot. However, the Authorization Code flow is sometimes also used by Native 
applications and other Clients in order to be able to obtain a Refresh Token, even when they
cannot ensure the secrecy of the Client Secret value. The Hybrid Flow combines aspects of the 
Authorization Code Flow and the Implicit Flow.

So i think it'll be interesting if the sample uses Hybrid Flow.