Anonymous login using OpenID or OAuth

Question

In short: Can I use OpenID oder OAuth for anonymous logins on my web service?

Described in more detail:

Scenario/Background: I'm going to provide online-tools for mental health related exercises. The users should be able to see their completed exercises after each login, but I don't want them to register at my service—because I don't want to store their e-mail adresses, passwords, not even nicknames or anything like that (not even hashed!), because it could reveal the users' identities. I want to keep their privacy perfectly safe by not storing anything that relates to the offline identity.

Problem: How to perform the login (or how to recognize recurring users) without credentials?

Approach(?): When I use my Google account to log in at some third-party web services, I'm asked wether I want to share my profile data, e-mail adress—and what else. Would it here be possible to reveal nothing? The only thing, the service would know, is that somebody has a google account and knows the password. To me, it's completely unimportant who the owner is, it's just important to recognize the same owner after each login—let's say by some kind of anonymous token id.

• Is this approach working?
• Are there other approaches for anonymous user logins—without storing data?

Answer 1

Use OpenID Connect. OpenID Connect is a specification built on top of OAuth 2.0 (RFC 6749). You can delegate user authentication to an Identity Provider (such as Google) that supports OpenID Connect.

An IdP will issue an ID token to you after successful user authentication. You can find the user's attributes such as name, email address, etc. in the ID token. So, you don't have to manage users' attributes any more if you use an external Identity Provider that supports OpenID Connect.

---

^{(Addition for the comment)}

OpenID Connect Core 1.0 has defined 6 standard scopes as listed below. These values can be included in scope parameter of an authorization request.

1. openid
2. profile
3. email
4. address
5. phone
6. offline_access

Among the above, profile, email, address and phone are defined in "5.4. Requesting Claims using Scope Values". They can be used to request some attributes of a user to be included in an ID token which will be issued by an authorization server. For example, when email is included in scope parameter, the ID token issued based on the request will contain values of email and email_verified (if the authorization server supports the attributes).

So, if you want to minimize the number of attributes contained in an ID token, avoid including profile, email, address and phone in scope parameter. In other words, scope parameter should contain only openid.