Do we have any public implementations of OAuth 2.0 MAC Token Profile..?
[1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05
Thanks & Regards,
Prabath
Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
Mobile : +94 71 809 6732
http://blog.facilelogin.com
ht
Bill - as you are referencing CORS in your message, I assume you are
discussing a Javascript-only (browser) client. I believe the implicit flow
was designed for this case and this flow never involves a confidential
client.
Confidential clients may be used with the other flows (code,
resource,.
So the Google AS is doing for the RS what an IdP typically does for a
third-party SP. Interesting. This is a pattern that I have thought useful in
the past.
I recall at CIS last year Vittorio mentioning that the Azure OAuth AS was also
putting that option out there as well, to see what RS’s m
I can’t give names or numbers but yeah, it’s happening. Especially for
Android apps, it’s easy & straightforward to get an ID token, and cheap to
validate on the server side. Obviously, it only works for Google accounts.
On Thu, Mar 27, 2014 at 2:40 PM, John Bradley wrote:
> I don't know what
I don't know what clients are using the play API to get 3rd party tokens.
Perhaps Tim Bray can comment on scale of use if not specific clients.
John B.
On Mar 27, 2014, at 3:36 PM, Lewis Adam-CAL022
wrote:
> I get the idea, but I’m trying to get a feel for whether or not this model is
> be
Bill,
I can't comment to how effective your use of "private metadata" is to
supporting effective authentication of clients. If you feel it is sufficient
than you could classify them as "confidential" since you are authenticating
based on the metadata.
I also can't comment on CORS as I am not
I get the idea, but I'm trying to get a feel for whether or not this model is
being built upon and to what extent.
So if I rephrase ... are there known 3rd party AS's out there in the wild that
are consuming the Google id_token?
Or any examples of a 3rd-party RS that is directly consuming it?
Handing out a id_token with a 3rd party AS or RS as the audience is the
standard way that Android apps that rely on Google as the source of identity
work on Android using the Google Play Services.
This describes the API
http://android-developers.blogspot.ca/2013/01/verifying-back-end-calls-from
Hi John,
With respect to Google Play handing out id_tokens, are any there any known
instances of that being used? Either to kick of an assertion flow with another
(non-Google) AS, or to present directly to a non-Google RS?
adam
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Thursday, Mar
I'm still trying to wrap my head around the differences between public
and confidential clients. In our IDP impl, we check redirect uris and
associate a lot of private metadata to the access code to ensure there
is no client_id swapping. My understanding was that confidential
clients made sur
a variant I've seen proposed is to to have
1) the native app obtain tokens from AS1
2) the RS only accept tokens from AS2
3) have AS1 request tokens of AS2 on back-channel to meet reqs of #1 & #2
lots of ways to 'close the loop'
paul
On 3/27/14, 10:06 AM, John Bradley wrote:
Hi Adam,
3 is th
Hi Adam,
3 is the most common today. In the Salesforce case it has the additional
benefit that when Domain 1 is federating to SalesForce via OpenID Connect it
can provide access tokens for it's API to sales force scoped for that user for
use in the SalesForce custom logic.
1 and 2 are similar
Hi Adam, we are confronting this issue in the NAPPS effort and are
exploring a model that resembles your Option 2
The Token Agent (TA) obtains an id-token from the first AS1, this
targetted at the second AS2 (the one local to the target RS). The TA
then exchanges that id_token at AS2 for an ac
I am curious it ping the thoughts of others on the list of how OAuth is going
to continue to mature, especially with respect to enterprise federation
scenarios. This is something that I spend a whole lot of time thinking about.
Specifically, consider the following use case:
An end user in dom
14 matches
Mail list logo
