FriendsOfSymfony / oauth2-php

A server implementation of OAuth 2.0
MIT License
515 stars 111 forks source link

Why only GET and POST methods allowed? #101

Open klandaika opened 7 years ago

klandaika commented 7 years ago

Is there a particular reason why makeRequest() of OAuth2Client only allows GET and POST HTTP methods?

A typical REST API involves PUT, PATCH, and DELETE which are impossible to use with the client at this time.

In the code i see a comment // Method override as we always do a POST. but not quite sure why is it that "we ALWAYS do a POST".

In our current project we will be overriding makeRequest() method to support PUT, PATCH, and DELETE, if you are interested I can submit a PR to add such support here as well.

Spomky commented 7 years ago

You are right, when a client makes API calls, it can use the methods you listed and not only GET and POST. However, when those requests are done in the context of the OAuth2 protocol, only POST and GET methods are listed.

The details of those requests are available in the RFC6749 section 4.

The client class you mentioned is a client from the authorization server point of view, not from the resource server one. No DELETE, PUT or PACTH requests are expected here.

klandaika commented 7 years ago

I'm a bit confused as to why authorization server would need a client. In my numerous implementation of OAuth only the resource servers would use client.

User tries to access resource --> redirect to Oauth Server --> User authenticates --> redirect back to resource server with code --> resource server POST code using the client to auth server.

Could you explain scenario when the auth server would need a POST? Also the comment in top of the OAuth2Client says:

OAuth2.0 draft v10 client-side implementation.

Based on that I assumed it was intended for resource clients which as I understand are the clients.

Spomky commented 7 years ago

In the OAuth2 context, each client must be register and is managed by the authorization server (see RFC6749 section 2).

To access on/modify/delete protected resources, the client must get an access token. This access token is delivered by the authorization server using flows listed in the same RFC. Unless new flows are created, interactions between the client and the authorization server are done through HTTP requests using GET and POST methods only.

Could you explain scenario when the auth server would need a POST?

The GET and POST methods are used in almost all authorization flows (see https://tools.ietf.org/html/rfc6749#section-4). The Implicit Grant Type uses only the GET method.

See for example https://tools.ietf.org/html/rfc6749#section-4.1.3

POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

When the access token is issued, it is consumed by the client on the resource server. The HTTP methods used by the client to interact with the resource server may be GET, POST, DELETE, PUT... It only depends on the resource server.

klandaika commented 7 years ago

Oh, this client class is meant for just getting tokens from the auth server, not for accessing the resources.

But if you were to add PUT, DELETE, and PATCH then it could be reused for accessing resources as well. Are you sure you don't want me to submit a PR for that?