1
votes

My needs:

  • Let's consider 2 end-users of the same domain.
  • User UA is the resource owner of resource RA.
  • User UA wants to delegate access of resource RA to end-user UB.

My main OAuth 2.0 interest comes from total token control (revocation at any time, etc.).


OAuth 2.0 Framework allows a client to act on the behalf of a resource owner with it's explicit permissions.

Oauth 2.0 defines resource owner and client roles (see the roles section) where:

  • Resource owner can be an end-user (that can grant access to a protected resource).
  • Client is an application making protected resource requests on behalf of the resource owner.

In the spec, the client is always considered as an application (with no particular implementation characteristics).

I would like to know if it is ok to implement OAuth 2.0 with an end-user as the client role or am I abusing OAuth completely?

My intuition is that OAuth 2.0 is only designed for third party application (with interoperability) and not for 2 end-users of the same domain. Am I right? In the other hand all the token mechanism really fits my needs.


PS: This expired OAuth specification (2010) talks about delegating authorization by a Resource Owner to another user via a Client using the OAuth protocol. But it's not that relevant.

1

1 Answers

0
votes

I would like to know if it is ok to implement OAuth 2.0 with an end-user as the client role or am I abusing OAuth completely?

Well, it is only an opinion of mine, but if, say, a Buffer can represent me posting my contents to Facebook using OAuth, why my friend Jack (a human, not robot) can't?

Of course, you must think it all over, especially in terms of security. But the abstract scheme looks fine by me.