{"id":900,"date":"2012-11-19T20:50:27","date_gmt":"2012-11-20T04:50:27","guid":{"rendered":"https:\/\/self-issued.info\/?p=900"},"modified":"2012-11-19T20:50:27","modified_gmt":"2012-11-20T04:50:27","slug":"oauth-2-0-multiple-response-type-encoding-practices","status":"publish","type":"post","link":"https:\/\/self-issued.info\/?p=900","title":{"rendered":"OAuth 2.0 Multiple Response Type Encoding Practices"},"content":{"rendered":"

\"IETF<\/span>OAuth 2.0 (a.k.a. RFC 6749<\/a>) has an extension point for defining additional response_type<\/code> values beyond the code<\/code> and token<\/code> values defined within the specification. The OAuth 2.0 Multiple Response Type Encoding Practices specification<\/a> uses this extension point to define the additional response_type<\/code> values id_token<\/code> and none<\/code>, as well as values for the combinations of code<\/code>, token<\/code>, and id_token<\/code>. These response_type<\/code> values are used by OpenID Connect<\/a>, as well as other systems using OAuth 2.0.<\/p>\n

I’m writing this now because I just updated the Multiple Response Types spec to add an IANA Considerations section to make IANA’s job easier when registering these additional response_type<\/code> values. No normative changes were made.<\/p>\n

The specification is available at:<\/p>\n