When you access a "resource" using OAuth you need to authenticate to a "server" which is at a different address from the resource. You need to know ahead of time the association between the resource, and the address that you request authentication from.
This is contrary to the way that the web works, and to the principles of REST. When you access a web page, you make a request to an address, and get a challenge. You then send the right credentials to the web page, and if you are authorized, you get the resource page. Everything is resource oriented because you always access the resource. How that resource is implemented is completely hidden from you.
But with OAuth, you get a challenge, but then you have to access another address which is not the address of a resource, but the address of a method that will get credentials. Think of this address as being the "getCredentials" address -- see, this is function oriented. Regardless of what page you access, what resource you access, you always go to a single "getCredentials" function. (Actually it is three different functions but that is too much detail for this discussion.)
The fact that it is not REST oriented is not a problem. We don't *have* to be REST oriented in all cases, and this is a standard we might as well use.
OAuth requires advance exchange of addresses
But the bigger problem is that I have to have advance knowledge in order to access something. Say I give you a URL of a resource: http://faahost:7777/airport/streetmap.jpg Knowing this URL will not be enough to access it! If you try to access this, you will get a challenge, but that challenge does NOT give you the additional information to finish the protocol. You must have set up, ahead of time, three addresses to the "faahost" which you must use in order to respond to the challenge. This is the case even if I am a well known user (and can prove it) and you have set up faahost to allow me access. The server running the BPM process will not be able to access this resource because it does not know the service addresses to the "getCredentials" service which it must response with.
Even if you tell the server trying to access that map the addresses of the "getCredentials" service to call, that is not enough. You must set up a unique "customer id" for every server pair. If your network consists of 100 servers, you must pair every server with every other server (9900 unique customer ids) JUST so they can authenticate users with each other.
OAuth Discovery Solves the Problem
OAuth Discovery starts with the first request to the service. If the calling program does not have the consumer id nor the service addresses in order to get the access token, then it sends a request to the service with the "Accepts" header set to be the type of the discovery document. The service, returns the discovery document, which contains the consumer id and the addresses of the three services needed. Then the calling program can initiate an OAuth interaction, involving the user, and ultimately getting an access token which can be used for access.
This resolves the problem because you no longer have to know the server (host) that a service is on. You access the service directly to find out what you need to know in order to do OAuth.
The attached diagram shows the interaction pattern AFTER Discovery has been used:
Last edited by Keith Swenson 12/15/2008(Effective date 12/15/2008)
You are viewing a static copy of
a project that was originally a wiki.
These pages can not be modified
at this location even though the page
may appear incomplete.
This copy was generated on
01/29/2012
and this project information has not been
changed since 12/15/2008.
OAuth (without Discovery) is not RESTful
When you access a "resource" using OAuth you need to authenticate to a "server" which is at a different address from the resource. You need to know ahead of time the association between the resource, and the address that you request authentication from.
This is contrary to the way that the web works, and to the principles of REST. When you access a web page, you make a request to an address, and get a challenge. You then send the right credentials to the web page, and if you are authorized, you get the resource page. Everything is resource oriented because you always access the resource. How that resource is implemented is completely hidden from you.
But with OAuth, you get a challenge, but then you have to access another address which is not the address of a resource, but the address of a method that will get credentials. Think of this address as being the "getCredentials" address -- see, this is function oriented. Regardless of what page you access, what resource you access, you always go to a single "getCredentials" function. (Actually it is three different functions but that is too much detail for this discussion.)
The fact that it is not REST oriented is not a problem. We don't *have* to be REST oriented in all cases, and this is a standard we might as well use.
OAuth requires advance exchange of addresses
But the bigger problem is that I have to have advance knowledge in order to access something. Say I give you a URL of a resource: http://faahost:7777/airport/streetmap.jpg Knowing this URL will not be enough to access it! If you try to access this, you will get a challenge, but that challenge does NOT give you the additional information to finish the protocol. You must have set up, ahead of time, three addresses to the "faahost" which you must use in order to respond to the challenge. This is the case even if I am a well known user (and can prove it) and you have set up faahost to allow me access. The server running the BPM process will not be able to access this resource because it does not know the service addresses to the "getCredentials" service which it must response with.
Even if you tell the server trying to access that map the addresses of the "getCredentials" service to call, that is not enough. You must set up a unique "customer id" for every server pair. If your network consists of 100 servers, you must pair every server with every other server (9900 unique customer ids) JUST so they can authenticate users with each other.
OAuth Discovery Solves the Problem
OAuth Discovery starts with the first request to the service. If the calling program does not have the consumer id nor the service addresses in order to get the access token, then it sends a request to the service with the "Accepts" header set to be the type of the discovery document. The service, returns the discovery document, which contains the consumer id and the addresses of the three services needed. Then the calling program can initiate an OAuth interaction, involving the user, and ultimately getting an access token which can be used for access.
This resolves the problem because you no longer have to know the server (host) that a service is on. You access the service directly to find out what you need to know in order to do OAuth.
The attached diagram shows the interaction pattern AFTER Discovery has been used: