This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
FAPI Pushed Request Object
FAPI Pushed Request Object

Version management

Difference between version and

At line 1 added 312 lines
!!! Overview
[{$pagename}] is a [draft|Draft Standard] by the [OpenID Foundation] as part of the [Financial API]
[OpenID Connect] and [OAuth] already support the transfer of [Authorization Request Parameters] parameters in [JSON] format in two ways:
* the request parameter may carry the request data in a [JWT]
* the [request_uri] parameter carries a URI referring to a place where the AS may retrieve the request object.
Both mechanisms contribute to the security of the request by allowing for the signing and [encryption] of the [Authorization Request] data.
The [Request_uri] additionally allows the client to just send the [URI] value in the [Authorization Request] as a pointer to the request object, rather than the full content of the request object itself, which allows for the transfer of larger amounts of request data without issues caused by [URI] length restrictions.
However, the [Request_uri] mechanisms also has some downsides. The client needs to maintain and expose request objects. This might look easy on first sight, but the client needs to be able to handle inbound requests from the [Authorization Server] and, potentially, store a large number of objects in its [database] including the need to properly clean them up.
The [Request_uri] mechanisms also means the availability and latency of the [authorization] process at the [Authorization Server] depends on the availability and latency of the client’s backend.
Moreover, in order to dereference the [Authorization Request Parameter] the [authorization] has to make outbound [HTTP] requests, which brings with it all the potential problems of [server-side] request forgery.
[{$pagename}] [specification] addresses these problems by moving the responsibility for managing request objects from the client to the [Authorization Server]. The [Authorization Server] offers an additional "request object endpoint". The client calls this [endpoint] to deliver its request objects and is provided with a unique [URI] for that particular request object, which in turn is sent into to the [Authorization Server]'s [Authorization_endpoint] as the value of the [request_uri] parameter.
This draft allows the client to send the request object via a direct [HTTP POST] request to the [Authorization Server] rather than as a redirect [URI] query parameter.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop