differenting between different profiles / request types

[Dick Hardt]

Currently in OAuth WRAP, we have different URLs at the AS for initially acquiring Access Tokens and for refreshing Access Tokens.

When acquiring an Access Token, the different profiles have different combinations of input parameters that an AS implementer needs to examine to disambiguate what to accomplish.

In the Profile Luke posted [1] he adds a parameter to indicate the Access Token is to be passed back via the callback URL.

An approach we could take would be to add a parameter to all the AS APIs that indicates the request. New profiles would add have a new request type string. We could remove the separate refresh token URL and have token refresh be another request type to the same URL.

-- Dick

[1] http://groups.google.com/group/oauth-wrap-wg/browse_thread/thread/4840fab6935e6fbc?hl=en

[Allen Tom]

Hi Dick,

Is the proposal to have a single URL on the Auth Server that can both issue
Access Tokens, and also refresh Access Tokens? The Auth Server would be able
to do determine which flow was being used based on a separate parameter?

If so, this is equivalent to the openid.mode parameter in the OpenID world.

Having a single URL that can both issue Access Tokens and also refresh
Access Tokens is OK with me.

Allen

> --
>
> You received this message because you are subscribed to the Google Groups
> "OAuth WRAP WG" group.
> To post to this group, send email to oauth-...@googlegroups.com.
> To unsubscribe from this group, send email to
> oauth-wrap-w...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>
>

[Marius Scurtescu]

The Authorization Server can always chose to use the same value for
Access Token URL and Refresh Token URL. Other than simplicity, is
there any advantage by specifying only one endpoint?

Adding a wrap_profile or _mode parameter is a good idea IMO.

Marius

[Dick Hardt]

On 2009-12-18, at 6:21 PM, Allen Tom wrote:

> Hi Dick,
>
> Is the proposal to have a single URL on the Auth Server that can both issue
> Access Tokens, and also refresh Access Tokens? The Auth Server would be able
> to do determine which flow was being used based on a separate parameter?
>
> If so, this is equivalent to the openid.mode parameter in the OpenID world.
>
> Having a single URL that can both issue Access Tokens and also refresh
> Access Tokens is OK with me.

yes, yes, I think so as well, good

Any disadvantages?

-- Dick

[Luke Shepard]

+1

The Authorization URL will still be separate, though, right? I think having one server-to-server URL and one user-to-server URL is sufficient. Refresh tokens are sort of optional anyway, so by making them the same URL it makes it easy for a developer to add support later without having to notify all their clients.

[Dick Hardt]

On 2009-12-19, at 12:22 AM, Luke Shepard wrote:

+1

The Authorization URL will still be separate, though, right?

That was what I was thinking since it is a page for the user rather than an API endpoint.

I think having one server-to-server URL and one user-to-server URL is sufficient. Refresh tokens are sort of optional anyway, so by making them the same URL it makes it easy for a developer to add support later without having to notify all their clients. 

Agreed.

-- Dick

[Allen Tom]

There's a little less flexibility in that both APIs have to be served from
the same host.

Allen