@marc-mabe I see your point and I agree that zend-expressive-authentication is more oriented for user's authentication. I tried to manage also client authentication (for OAuth2) using the term identity instead of user's ID. I also added the UserInterface::getDetails() to return all the information about the identity (including also client_id for OAuth2). Actually, I also added this code to create an identity instance to manage user and client_id at the same time.

Possible solutions:
I think the Zend\Expressive\UserInterface naming can be definitely confusing and we should change it to Zend\Expressive\IdentityInterface to manage both users and clients.
Another idea will be to create another Interface, something like Zend\Expressive\ClientInterface for returning a specific client object.

@marc-mabe thoughts?

Hi @ezimuel,

Retrieving an object of UserInterface with a requirement to check that this is actually a user is indeed super confusion.

Introducing an Zend\Expressive\IdentityInterface totally makes sense for me ... but actually I would guess that most users still just assume this to be a user identity and such assumption can lead to terrible security leaks.

I like an additionalZend\Expressive\ClientInterface more ... but in this case we only have the one or the other. Also doesn't it make more sense to have in in zend-expressive-authentication-oauth2 ?

What about something like that ?:

namespace Zend\Expressive\Authentication;

interface UserInterface {
    public function getUserIdentifier(): string;
}

class DefaultUser implements UserInterface {
    public function getUserIdentifier(): string;

    /** @deprecated */
    public function getIdentifier() { return $this->getUserIdentifier(); }
}

namespace Zend\Expressive\Authentication\OAuth2;
use Zend\Expressive\Authentication\DefaultUser as BaseDefaultUser;

interface ClientInterface {
    public function getClientIdentifier(): string;
}

class DefaultUser extends BaseDefaultUser implements ClientInterface {
    public function getClientIdentifier(): string;
}

class DefaultClient implements ClientInterface {
    public function getClientIdentifier(): string;
}

@marc-mabe I like your approach but I would like to find an alternative solution without a BC break of Zend\Expressive\Authentication\UserInterface. A part from OAuth2, the authentication is used by others adapters: zend-expressive-authentication-basic, zend-expressive-authentication-session, and zend-expressive-authentication-zendauthentication.
Moreover, regarding the OAuth2 identity, I think we need to care also of the other information like token_id and scopes, see here.

The problem is that in OAuth2 there are two identities that needs to be authenticated - a client and optionally a user but zend-expressive-authentication only supports one identity - the user identity.

The only BC break I see would be the renaming of UserInterface::getIdentity to UserInterface::getUserIdentity. This can be solved at least for the DefaultUser implementation as in previous example and getIdentity could be kept as deprecated in UserInterface but you are right that all other implementations would need to get updated. And a deprecated method on an interface would lead to later BC breaks where it gets removed.

The only way to solve that would be to keep the method UserInterface::getIdentity but introduce ClientInterface::getClientIdentity.

• zend-expressive-authentication (no change needed)
• AuthenticationInterface only authenticates users
• AuthenticationMiddleware populates attribute UserInterface
• zend-expressive-authentication-oauth2
  • OAuth2Adapter implements AuthenticationInterface requires an authenticated user
  • ClientAuthenticationAdapter requires an authenticated OAuth2 client
  • ClientAuthenticationMiddleware populates attribute ClientInterface

This way you can use:

• AuthenticationMiddleware if you require an authenticated user
• ClientAuthenticationMiddleware if you require an authenticated oauth2 client
• AuthenticationMiddleware + ClientAuthenticationMiddleware together if you need both

Moreover, regarding the OAuth2 identity, I think we need to care also of the other information like token_id and scopes, see here.

I think this information just needs to go into user/client details as it happens already at least for now.

@marc-mabe I've done some propotypes in order to support a UserInterface and a ClientInterface for zend-expressive-authentication. The PR with the propotype is zendframework/zend-expressive-authentication#39.

I introduced a new IdentityInterface and created a UserInterface that extends it. The ClientInterface should be implemented in zend-expressive-authentication-oauth2, as you suggested. This solution should prevents BC breaks for existing implementations.
Thoughts?

sorry for the super late response - LGTM 👍

Running into this. There's a simple bug here that makes it difficult to load the client for client_credentials grant. The $userId is never null since the oauth_user_id request attribute is never null. Instead, it's an empty string. That is arguably an issue with lcobucci/jwt#249 since the sub claim in the JWT is an empty string. The workaround is to use the oauth_client_id from the $details array.

webimpress requested my review here.

The past year I've digged deeper into OAuth2 and gained a lot more knowledge. The issue with OAuth2 is that it is not really designed for user authentication. There is the password grant but it is not considered good practice. A better approach would be OpenID Connect.

Having said that, if you own and or trust the server AND the application which requests a user authentication, only then the OAuth2 password grant could be used. In all other cases OpenID Connect should be used for user authentication.

I agree that an IdentityInterface makes more sense. And adding OpenID Connect for user authentication would be welcome.

Merged to master and develop for release with 1.2.1!