On Thu, Apr 29, 2010 at 12:45 PM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > 3.5.2. Web Server Flow > 3.5.2.2. Client Requests Access Token > > The client obtains an access token from the authorization server by > <snip> > secret_type > OPTIONAL. The access token secret type as described by > Section 5.3. If omitted, the authorization server will issue a > bearer token (an access token without a matching secret) as > described by Section 5.2. > > -------- > A client may indicate the desired response format using an Accept-Header > specifying > one of the following mime types: application/x-www-form-urlencoded, > application/xml, > or application/json. If not specified, the default response format is > application/json. > (Alternatively, the response format could be specified by a query parameter) > -------- > > For example, the client makes the following HTTPS request (line > breaks are for display purposes only): > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > -------- > Accept: application/json > -------- > > type=web_server&client_id=s6BhdRkqt3& > client_secret=gX1fBat3bV&code=i1WsRn1uB1& > redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Why not allow the request to be JSON encoded as well? The only non-JSON requests and responses are those that go through the User Agent as query parameters. How about encoding with JSON in these cases as well and putting the whole JSON blob into a query parameter named like oauth_request/oauth_response? This would make all requests/responses consistent and eliminate possible collisions. Do we still have to support application/x-www-form-urlencoded? Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
