OAuth Operations: GET or POST?
Many of the Akana OAuth operations are available with either HTTP GET or POST. This is per the OAuth specification. Each of these pairs of operations has essentially the same functionality, but relays the information in different ways.
Below is some additional information on the differences between the two approaches.
For a summary of the OAuth operations available, see OAuth Services: Overview.
Logging/Security
In a lot of cases, as messages are relayed from one system to another, message logs record the URL, including all query parameters. In general, in the case of POST operations using Form parameters, the information becomes part of the payload, which is generally not logged. For this reason, POST can be considered to be a little more secure than GET.
URL length limitations
When a message is sent using HTTP GET, all the OAuth information is sent in the query parameters, which are part of the URL. Sometimes this is a lot of information. For example, if the id_token is included in the parameters, the URL could get very long.
Some browsers and applications have URL length limitations, and will strip the URL or refuse the message if the URL is longer than a certain size.
Depending on the general length of your OAuth messages and the systems you are using, this might be a reason to choose HTTP POST rather than GET.
Header buffer limitations
Some applications place a limit on the header buffer. When OAuth information is sent via HTTP GET, the information is conveyed in query parameters, and some of the values might be quite long. Query parameters go into the header. If there is a limitation on the header buffer, this could result in the message being cut off and/or refused.
Depending on the general length of your OAuth messages and the systems you are using, this might be a reason to choose HTTP POST rather than GET.
