Creating new clients in OAuth2 implementation

[manuelro]

I've been playing around with Apigility, the framework does a great job. However, I've been trying to figure out how to implement OAuth2 in a mobile application.

After following the OAuth2 implementation guide, I'm now wondering how to create new clients. I have a workflow I think could work well in my mobile app:

1. User creates a new account (system creates a new client with client_id, password, username, etc - based on OAuth2 example)
2. User signs in
3. System returns token
4. Client uses the token to access the protected API

I would be using the Username and password access for Public Clients (based on the OAuth2 guide in Apigility's website).

The issue here is how to create a new user in the OAuth2 client table, I was expecting a POST request to mydomain.com/oauth/clients but of course that doesn't work.

Whats the right workflow to achieve this in Apigility?

[TomHAnderson]

A User has Clients. The Client table has a reference to User.

This allows one User to have multiple Clients; one per application which implements your API. This diagram may help but it uses a disconnected User so the relationships to User are not mapped.

[manuelro]

I think I haven't got this straight. Users can be a simple service under my API. How do I connect the users with the clients? Is it done manually? Do Apigility has a faster way for doing this?

[TomHAnderson]

You want specific users to have access to a specific client. That's not what OAuth2 does. You will need to authenticate your users against a list of permissioned clients in order to issue an access token.

Look at it this way: At Facebook if I create a client for my app how do I filter the people that can use my app? I believe the correct answer is: "I don't". The Client entity is owned by a user and there is no other security about who can use a client as long as the authorization code handshake can be performed.

A user is connected to a Client through an Authorization Code, Access Token, or Refresh Token. The user USING the app is linked from one or all of these Tokens. So given a Client A owned by user 1 where users 2 and 3 are authenticated using the Client A credentials user 1 is the client owner and users 2 and 3 are authorized for Client A.

[manuelro]

I think this thread can be closed. Apigility is not what I'm looking for, it'll be better to have more granular control over what's going on behind the stage, Laravel will do the job very well. Thanks!

[michalbundyra]

This repository has been closed and moved to laminas-api-tools/api-tools; a new issue has been opened at laminas-api-tools/api-tools#31.