Class LinkingOAuth2UserService

java.lang.Object
com.codename1.backend.security.oauth2.client.LinkingOAuth2UserService
All Implemented Interfaces:
OAuth2UserService<OAuth2UserRequest, OAuth2User>
public final class LinkingOAuth2UserService extends Object implements OAuth2UserService<OAuth2UserRequest, OAuth2User>

Signs the user of an identity provider in as a user of the application's own.

LinkingOAuth2UserService linking = new LinkingOAuth2UserService(identities, users);
linking.setCreateUsers(true);
http.oauth2Login(oauth2 -> oauth2
        .userService(linking)
        .oidcUserService(linking.oidc()));

Who the provider's user is here is decided in this order:

  1. An identity -- this provider, this subject -- that is tied to a local user already signs in as that user. Nothing else about the provider's answer is consulted: not the email, which may have changed since.

  2. Otherwise the provider must say the user's email address is one it has verified. An address it does not vouch for is refused with EMAIL_NOT_VERIFIED, whether or not anybody here has it: tying an account to an address somebody merely typed at a provider would hand that account to them.

    A provider whose registration names a ClientRegistration.ProviderDetails.getUserEmailsUri() -- GitHub, whose user carries no such flag and often no address -- is asked there instead, with the user's access token: the address is the one the list marks both primary and verified, and whatever the user info said of an address is not consulted. No such entry, or a list that cannot be read (the user:email scope was not granted), is refused the same way.

  3. A verified address that is the name of a local user ties the identity to that user, and signs in as them.

  4. A verified address nobody here has makes a new local user of that name -- when setCreateUsers(boolean) allows it and the users are a UserDetailsManager -- and is refused with ACCOUNT_NOT_FOUND otherwise.

The user that comes back is named after the local account and has its authorities, with the provider's attributes beside them; a second factor and remember-me, which go by name, then apply to it exactly as they do to a sign-in with a password.

A new user has a password nobody knows: 256 random bits under an encoding id no encoder has. They sign in through the provider until they set one.