On 09/03/2012 10:25 AM, Sergey Beryozkin wrote:
On 10/08/12 17:18, Dick Hardt wrote:
As an implementor, I would pick a signed JWT over OAuth 1.0A. Just
saying.
Given that, there is also a clear need for signing an HTTP(S) request
as some sites are choosing OAuth 1.0A over OAuth 2.0 because th
With the core specs basically out the door and seeing wider adoption and
publicity, the OAuth community is going to start to get more questions
about "how do I do X?", and many of these are questions that have been
answered before or seem "obvious" to those of us who have been up to our
ears in
Forgot to address this bit directly:
So why not directly send the exact expiration time of an access token?
As Bill said, this question of "expires_in" vs. "expires_at" was
discussed in depth on the list. The truth is, "expires at" is
susceptible to clock skew between the server and client
First, note that the "expires_in" field is never communicated to the
Resource Server. It really is only just a hint to the Client. The Client
has no way of even communicating this hint to the Resource Server within
the bounds of OAuth.
Second, the connection between Resource Server and Authori
In my personal view, 1.0a is technically obsoleted but still useful,
especially for cases where 2 doesn't offer a solution right now. If you
can specify a way to bind to different token/signature types, you'd be
able to leave yourself the flexibility.
-- Justin
On 08/14/2012 03:21 PM, Willia
I would argue that it's exactly the process that you describe below that
makes my original comparison accurate. As a strawman example, OAuth2
core specifies a bunch of parameters that get sent to the Auth Endpoint,
like scope and response_type. OpenID Connect defines a few more, like
display. I
On 08/10/2012 12:48 PM, Dick Hardt wrote:
On Aug 10, 2012, at 9:28 AM, Justin Richer wrote:
On 08/09/2012 06:47 PM, Dick Hardt wrote:
On Aug 9, 2012, at 1:08 PM, Justin Richer wrote:
With MAC, you should be able to re-use about 80-90% of your
existing codepath that's in place for B
On 08/09/2012 06:47 PM, Dick Hardt wrote:
On Aug 9, 2012, at 1:08 PM, Justin Richer wrote:
With MAC, you should be able to re-use about 80-90% of your existing
codepath that's in place for Bearer, simplifying the setup below.
That makes no sense, I would be adding MAC to the sites
The reason is simple: to benefit from the rest of the improvements in
the OAuth2 framework. These are just the ones off the top of my head:
1) Multiple means for getting a token (all the flows are now available)
2) No request tokens
3) No reliance on per-client secrets (though, addendum, I think
With MAC, you should be able to re-use about 80-90% of your existing
codepath that's in place for Bearer, simplifying the setup below.
I would figure that the "variant of OAuth2" issue is a red herring
because not everyone out there is fully spec compliant. If they were,
you wouldn't have so m
Use case #2: signature protection over plain HTTP parameters
MAC gives us message-level signing in a way that doesn't require all the
parameters to be packed into an extra structure, like JWT/SAML do. TLS
gives no application-layer verification of integrity of parameters, nor
does it give you
er message signing will likely still be one of the mechanisms.
The chair will need to decide if we start fresh and copy the parts of MAC that
are needed or try and continue the existing MAC draft.
John B.
On 2012-08-08, at 4:59 PM, Justin Richer wrote:
I believe that there's value in per-
On Aug 8, 2012, at 6:08 PM, Justin Richer wrote:
Thanks Justas. The MAC document is currently without an editor within the WG,
so this is the best place to record the error.
A wider note to the WG: I wouldn't mind taking over editorship of the MAC token
document so long as I could ge
Thanks Justas. The MAC document is currently without an editor within
the WG, so this is the best place to record the error.
A wider note to the WG: I wouldn't mind taking over editorship of the
MAC token document so long as I could get a co-editor with enough
cryptographic expertise to make s
I agree with the idea that we need to collect and document some best
practices around the UX of authorization, especially in the case where
it's the end user making the determination. There have been a few chirps
about this in the past, but I haven't seen anyone really stand something
up. The O
The approval screen is a detail of the UX that the protocol itself
doesn't address, since there are several instances where an approval
screen does and does not make sense.
If you're doing a "trust on first use" (TOFU) scenario where the
resource owner is the same as the end user (remember, th
Implicit grant makes perfect sense when the user agent and client are
collapsed into a single entity. In other words, if your client is inside
the user agent then doing a code flow doesn't actually buy you any extra
security. This is the driving design decision behind having it in there,
and fr
I'm generally OK with the change, though it does change One problem I
have with this is that it can give a false sense of security about the
information being sent to the token endpoint and how trustworthy it is.
A client_id is public knowledge, and so someone impersonating a client
on the Auth
It's all about how you can swipe a token and inject it into another
application. It's easier to trap and inject a token in the implicit flow
because it's exposed to the user agent and there's no client secret tied
to the token's issuance. To get the same trick to work with the code
flow on serv
3)If I wanted to use OAuth, the client would send an authorization
request to the server's AS, which would authenticate the user of the
client, and ultimately result in the client possessing an
access-token. My thinking is that this access token (let's assume
it's a JWT) would contain the
set.
Other's thoughts?
Cheers,
-- Mike
*From:*Justin Richer [mailto:jric...@mitre.org]
*Sent:* Friday, June 15, 2012 11:53 AM
*To:* Mike Jones
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and s
n
On 06/15/2012 02:15 PM, Justin Richer wrote:
Why not percent encoding for just colon and percent?
-- Justin
On 06/15/2012 01:30 PM, Mike Jones wrote:
I was asked a question off-list, which I think is worth answering
on-line. The question was: Why the Tab character, rather than
Why not percent encoding for just colon and percent?
-- Justin
On 06/15/2012 01:30 PM, Mike Jones wrote:
I was asked a question off-list, which I think is worth answering
on-line. The question was: Why the Tab character, rather than
%-encoding?
Introducing % encoding would break all exi
I agree with Doug and George's reading: nuking the refresh token gets
rid of all access tokens associated with that refresh token's lifetime.
This includes both simultaneous issuance as well as derived issuance.
-- Justin
On 06/11/2012 08:13 PM, doug foiles wrote:
Hi Paul and George,
Even th
Agreed with Eran, there shouldn't be restrictions on most of these
fields. Though it should address Julian's request of how do you define
encoding on these fields explicitly.
-- Justin
On 06/04/2012 03:16 PM, Eran Hammer wrote:
The ABNF must reflect the existing draft, not invent new restri
ve me an unstructured token.
3. even if I could get a JWT (which I would definitely be interested in
exploring) the unstructured token still gives my major bandwidth advantage
(again, because of my edge cases).
Tx!
adam
-----Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
First, I have to give proper credit to my colleague Amanda Anganes for
making those flow diagrams (which I agree are pretty awesome -- when
coding I refer to them as often as the spec text itself, personally).
Yes, you have it right, in this case the RS is the client of the
identity API from t
I also think it's worthwhile. OAuth2 doesn't provide a way to do a
signed-http-request in the way that OAuth1 does. I would definitely like
to see this draft make its way to completion, but I don't have the
crypto expertise to pick up editing it myself.
-- Justin
On 05/16/2012 11:51 AM, Will
This kind of fully automated approach isn't solved yet. OAuth isn't
quite as simple as HTTP Basic and its kin, where the user agent can
collect everything it needs directly and just push it back to the
protected URL. In order for this to truly work, you need to have not
just a pointer to the is
It's important to remember that these identifiers need to be handled,
seen, and remembered by people. Especially in the long-tail case (which
is to say, IdPs who aren't big enough to get a log in button), users
will need to enter a piece of text into a website to tell the website
who they are.
word Credentials, and the Client Credentials flows. These were
inspired by the diagrams for 1.0 and 1.0a that Idan Gazit posted in
http://www.ietf.org/mail-archive/web/oauth/current/msg00696.html,
which Justin Richer pointed me to when I first started trying to read
and understand the OAuth2.0
As I understand it, the tag of "Yukon Day" is a suggestion and doesn't
change the unconference format, and IIW attendees are free to ignore the
theme, just like NSTIC day last time around.
-- Justin
On 04/23/2012 10:22 AM, John Bradley wrote:
I was talking to Phil last week and Thursday is o
18.04.2012 22:01, schrieb Justin Richer:
Not all implementations in the field that do this are using JWTs as
the tokens. Ours in particular used a random blob with no structured
information in it. The endpoint returned a JSON object.
-- Justin
On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote:
).
regards,
Torsten.
Am 16.04.2012 21:04, schrieb Justin Richer:
OK, but with SWD and discovery off the table, can this now be
considered to be within that manageable number instead?
We wanted to keep the # of WG items to approximately 5. Once we finish
some of these items and get them off our
So it's a "known issue". I think that's an artificial reason to leave it
and a reasonable section to be cut out first.
-- Justin
On 04/18/2012 03:51 PM, Eran Hammer wrote:
Because it is in the draft the WG is suppose to consider. It's a stated
dependency.
EH
-Original Message-
Fro
It was also my understanding that this was for something outside of IIW,
in addition to whatever happens *at* IIW. Nothing's stopping there being
various IIW sessions on topic as well, but there's something to be said
for getting together for a few hours at a shot without the distractions
of th
OK, but with SWD and discovery off the table, can this now be
considered to be within that manageable number instead?
We wanted to keep the # of WG items to approximately 5. Once we finish
some of these items and get them off our plate we could roll new items
onto the plate, theoretically.
Thursday would conflict with IIW sessions proper, and we'd prefer a
Friday morning get together.
-- Justin
On 04/16/2012 12:27 PM, John Bradley wrote:
Thursday morning works for me as well.
John B.
Sent from my iPad
On 2012-04-16, at 6:14 PM, Phil Hunt wrote:
Can do, but would prefer a
only wanted to take on a manageable number
of tasks at once.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Friday, April 13, 2012 10:02 AM
To: Hannes Tschofenig
Cc: oauth@ietf.o
Did the "Introspection Endpoint" or "Methods for connecting a PR to an
AS" get dropped? There seemed to be interest in the list in coming up
with a generally applicable scheme, or set of schemes, to do this, and
there are certainly no shortage of starting points. Both AOL and Ping
have their ow
If the mobile device has a web browser (such as a smart phone), then
this is pretty easy, and you've got a couple of options.
One of the best options when the token is on behalf of an end user is,
in my opinion, to use the authorization code flow like this: First,
register what's called a "pub
The "scope" attribute is a space-delimited list of scope values
indicating the required scope of the access token for accessing the
requested resource. In some cases, the "scope" value will be used
when requesting a new access token with sufficient scope of access to
utilize the
http://tools.ietf.org/html/draft-ietf-oauth-assertions-01
Section 7's second portion about a client including multiple credentials
types seems buried down here in the Error Responses section for
something this fundamental. It also conflates discussion of selection of
this client authorizat
I think it's a matter of politics and semantics: The real question is
what do we officially build the IETF version off of? The WG can't
officially start with the OIDF document due to IETF process, which makes
sense. But there's nothing that says we can't start with Thomas's draft
and be heavily
Makes sense to me, except that I think the token_type value is typically
lowercase "bearer", though it's defined to be case insensitive in
Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the
value of this field for the Bearer token type ever got defined anywhere.
Section 7.1 ref
OK.
Thanks for the explanations so far. It's very helpful.
I'm prototyping the framework support for OAuth 2.0 and at this stage
I'm trying to figure out what exactly the runtime itself can do and what
has to be delegated to the custom code and thus how to design the api
the runtime and the cust
I think clarification text makes sense here because we're importing a
term from a foreign spec -- b64token -- that overlaps with a term
meaning something quite different in our spec -- token. We can't really
change either of these terms, so we need to separate them some other way.
-- Justin
O
Shane is right; the way you described your problem, the client
credential grant type may be appropriate. That's especially true if
the client will be accessing resources that don't necessarily belong
to specific users. But if the client (web site) will be using the API
(OAuth auth/resource serv
+1 to André's suggestion below.
If you find that you're going to have to add a field to your API to
indicate the userID along with a two-legged transaction, you're likely
doing things wrong.
We've used the auto-approve method below for several applications, and
users don't seem to know or ca
On 02/15/2012 04:33 AM, Songhaibin wrote:
I've reviewed this document as part of the transport area directorate's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors for
their information
In most cases, it will likely be a fixed value, but there's nothing
indicating that it can't be contextual. Especially in cases where you've
got public, confidential, and dynamically-registered clients all acting
on the same host, the default value will depend completely on what kind
of client
Responses inline. Don't know if you want to forward these to the
appropriate other lists/authors as well.
On 02/07/2012 01:04 PM, Eran Hammer wrote:
-Original Message-
From: Henry S. Thompson [mailto:h...@inf.ed.ac.uk]
Sent: Tuesday, February 07, 2012 9:31 AM
To: apps-disc...@ietf.org;
+1 for consistent examples.
-- Justin
On 02/06/2012 02:35 PM, Eran Hammer wrote:
Sending to the right place.
*From:*Thomas, Christopher (LLU) [mailto:cwtho...@llu.edu]
*Sent:* Monday, February 06, 2012 11:33 AM
*To:* draft-ietf-oauth...@tools.ietf.org
*Subject:* Mail regarding draft-ietf-oau
respectfully submit it
to the editor and working group for consideration of inclusion in this
section.
-- Justin
On 01/26/2012 12:49 PM, Eran Hammer wrote:
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, January 26, 2012 6:07 AM
To: Eran Hammer
Cc:
I realize that -23 is already published with the below text, but since
this is a whole new section and nobody else seemed to bring it up, I
wanted to make sure it wasn't missed by the WG.
Suggested non-trivial clarifications:
-
(1) 1.3.4 - "previously arran
My agreement was, and is, to the *production* rules and not the
*parsing* rules. So long as the former is a proper subset of the latter,
everything is fine. What's happening here is that the spec is being read
-- by experts -- as if it were superceding the latter, and that's not a
good thing.
Keep in mind that a major purpose of this document is to encourage best
practices by well-meaning developers. We want to make it clear for
people who want to do the right thing what the right thing to do is. No
document in the world will make ill-meaning developers do the right thing.
-- Just
+1, sounds reasonable to me and I don't see why not. Also, it fits with
current implementations that I'm familiar with.
-- Justin
On 01/20/2012 06:19 PM, Eran Hammer wrote:
The current text:
If the issued access token scope
is different from the one requested by the client, the autho
Precisely, and without a strong consensus of use in practice today,
getting the semantics right around a new parameter (even if optional)
doesn't make sense this late in the game. The information in the token
response is easily extensible by other documents, and it should go there
if people rea
//support.google.com/mail/bin/answer.py?hl=en&answer=1173270
Any thoughts on application-specific passwords. Do you think an
authorization server could implement application-specific passwords,
passing it off as the "client credentials" grant type. Would that be
in spec?
Cheers,
What you're describing is the Device Flow, which was pulled out of the
main document a while ago and now sits here, somewhat outdated and unloved:
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00
In this, the app gives the user a short code that they enter into a URL,
do the author
The important thing to realize here is that just having the client_id
doesn't get you access tokens, and it certainly doesn't give you access
to all access tokens issued to that client_id in the past. It does allow
for a phishing scenario in that it will let you try to impersonate a
known-good
I'm OK with the threat document including a line this this, or Eran's
proposed text, in the introduction to what OAuth can and can't do. It's
important to set scope appropriately. (and I am very sorry for that pun)
However, the contention about native apps that Mike brings up is
misleading for
29-80 Mailto: alexey.skolya...@dins.ru
<mailto:alexey.skolya...@dins.ru>
*From:*Justin Richer [mailto:jric...@mitre.org]
*Sent:* Monday, December 19, 2011 7:01 PM
*To:* Alexey Skolyarov
*Cc:* Buhake Sindi; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] conflict: error response invalid_request
llation, such as OpenID Connects Client
Registration spec, or 2) a distribution channel in which uniquely
credentials can be packaged into the binary before delivery)
- public clients (no option of client authn, but still possible to
have some protection against token leakage via other mitigat
Native mobile clients can't really be confidential clients.
The distinction between "public" and "confidential" clients is whether
or not they can keep deployment-time secrets; which is to say, a
client_secret. This is not to say that they can't keep *any* secrets. In
particular those generate
The spec already says that you can't repeat request parameters on the
line like that, so that's an invalid_request error, as described in
section 5.2:
5.2. Error Response
The authorization server responds with an HTTP 400 (Bad Request)
status code and includes the following param
Agreed -- I think that this text addresses the concerns of those who had
them without getting in too deep to things that are, quite frankly,
ancillary to OAuth. I still contend that the vast majority of
implementors reading this will see that line and say "Oh, I need an
https there instead of a
+1
Very well said, Hannes.
-- Justin
On 12/08/2011 09:18 AM, Hannes Tschofenig wrote:
Hi all,
I read through this rather long mail thread again and see whether we are
reaching any conclusion on this discussion.
In turns out that there are actually two types of discussions that relate to
ea
I agree that the core should remain token agnostic. However, I do see
value in MAC. The ability to have parameter values signed by a client
key is important for security in depth, even in a world of pervasive
server-side TLS. I would like to see MAC tokens mature to the point
where we could use
Forwarding my response to the list. (oops)
-- Justin
Original Message
Subject:Re: [OAUTH-WG] Mandatory-to-implement token type
Date: Fri, 02 Dec 2011 15:07:39 -0500
From: Justin Richer
To: Stephen Farrell
I still don't think that having an MTI token
Specifically, the DELETE method was rejected as tokens aren't
necessarily directly URL-addressable from the token endpoint.
Shoehorning that requirement in order to make it feel more RESTful was
more of a hack than a few folks (myself included) really wanted to make.
-- Justin
On 11/29/2011
+1 to dropping cookies.
On 11/19/2011 10:33 AM, Eran Hammer-Lahav wrote:
I would like to drop the cookies support defined in the MAC document
due to lack of interest from the browser vendors. At this point it is
most likely going to be an unimplemented proposal. If there is
interest in the f
Agree with Rob here. Also, from an application and service developer's
perspective, the check for "TLS compliance" is going to go something
like this:
1) Does that url start with "https"?
2) If yes, I'm compliant!
3) If no, make the url start with "https"
4) Done!
Which will put us in exactly the
> 1. Should we specify some token type as mandatory to implement? Why
> or why not (*briefly*)?
No, since I do not believe that the force of compliance with this one
point of the spec will be enough to persuade those who don't want to use
whatever the MTI token type ends up being to use it. Let's
On Tue, 2011-11-15 at 12:41 -0500, John Joseph Bachir wrote:
> Thanks Justin - some more questions below...
> > What does "public" mean here? In what sense could a client
> be
> > public or private, and why is implicit grant more
> appropriate for the
> > pu
> The spec says that this grant type is "optimized for public clients
> known to operate a particular redirection URI".
> (a) What does "public" mean here? In what sense could a client be
> public or private, and why is implicit grant more appropriate for the
> public case?
Section 2.1, client ty
This is exactly what I was thinking of. If a given token type is MTI for
clients, but servers can do whatever they want (this, as I read it, is
what was suggested), how does the MTI bit help interop at all?
-- Justin
On Wed, 2011-11-02 at 15:48 -0700, William Mills wrote:
> I actually think the
Please clarify what you're asking, if you would: There are two kinds of
authentication which happen with OAuth: client authentication and user
authentication, and neither of which are standardized on two-way TLS.
Client authentication happens at the token endpoint and is described in
section 2.3,
+1
Leave the current text as is, keep this part of OAuth token-type
agnostic.
-- Justin
On Wed, 2011-11-02 at 13:18 -0700, Phil Hunt wrote:
> +1
>
>
> Phil
>
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
>
>
>
>
>
> On 2011-11-02, at 1:06 PM, John Bradley
+1
I would also prefer to not restrict scope values but provide clear
encoding for places where transport is going to be an issue. This is
what we do with tokens, which show up in the same places. Am I missing
the reason we can't use the exact same rules (modulo the single space
character) that ap
I also want to voice support for this. We've implemented an earlier
version of this on a few of our projects as well.
-- Justin
On Fri, 2011-09-16 at 16:06 -0400, Chuck Mortimore wrote:
> If it's not already implicit by our implementation, I'm voicing our
> support for this becoming a working gr
+1, this wording is much clearer to me, too
-- justin
On Tue, 2011-09-13 at 19:25 -0400, Greg Brail wrote:
> This part of section 1.1 is confusing to me and I stumble whenever I
> read it – I see that Brian Eaton suggested looking at it a while back
> but I don’t think it got changed:
>
>
>
Ah, guess that settles it then. Mike, if you have any suggested text to
make this point clearer in the spec, this is probably the best place to
put it.
-- Justin
On Tue, 2011-09-06 at 23:52 -0400, Manger, James H wrote:
> A strange aspects of this thread is that the current draft already talks
Mike,
I think this is a red herring. as this vector has nothing to do with
mobile apps. The attack that you've suggested is also possible with a
compromised browser on a desktop using the web flow. In this case, the
browser (UA) can steal the user's credentials and hand them to whoever
they want t
Mike,
The basic argument here is that if the app wants to do bad things, and
you go through the process of authorizing it, it's going to be able to
do bad things. Not just to your stolen credentials, either, since it's
now got an access token too.
OAuth's trust model does work with installed appl
You can actually issue a JWT as an access token (since OAuth doesn't
care about the token format), so in this case the JWT would be used to
get access to the widget provider. The JWT would be a pre-signed bearer
token that the provider would know how to check.
-- Justin
On 9/2/2011 6:50 PM,
This description actually sounds a lot like the user-agent flow (aka,
"implicit authorization grant") in OAuth2 more than it does a true
two-legged system. The user is still there, and there's still a client
and protected resource, it's just that they're fairly tightly tied.
When using the implici
> >> 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token,
> >> Refresh Token
>
> >Not sure. What do others think? I put access token first because it is a
> >more important term to get out of the >way.
>
> I would rather consider to change order to Access Token, Refresh To
Comments inline.
On Wed, 2011-08-17 at 14:15 -0400, Eran Hammer-Lahav wrote:
> Thanks for the feedback.
>
> > -Original Message-
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Justin Richer
> > Sent: Thursday, August 11, 20
As I recall, the logic of the group here was something like:
"We want transport-layer encryption, so let's grab the latest version of
that around, which looks to be TLS 1.2"
With that logic in mind, this relaxation makes sense to me. Does anyone
remember this requirement differently?
-- Justin
uot;Those designing additional methods should evaluate
the compatibility of the normalized request string with their
own security requirements."
-- Justin Richer
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
structures. If bearer tokens are passed in page URLs, attackers
might be able to steal them from the history data, logs, or
other unsecured locations."
-- Justin Richer
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
In addition to taking another read through the document myself, I asked
another developer here to give it a once over. She's never implemented
an OAuth client or server, but has knowledge of what it's for. Thus, an
experienced developer new to building with OAuth2 -- a key target
audience for these
Isn't this what section 1.5 is already there for?
Refresh tokens are credentials used to obtain access tokens. Refresh
tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token
becomes invalid or expires, or to
I would avoid using the term "open" here as it has other deep-seated
meanings in the software world, particularly with regard to Open Source
and Open Standard stuff. FWIW, I think "confidential/public" or
"private/public" are serviceable.
-- Justin
On Mon, 2011-07-25 at 02:45 -0400, Eran Hammer-
I'm not sure normative language even fits here. We need something like
"Authorization codes should be treated as sensitive and the client needs
to try to make sure it doesn't leak the authorization code." But more
formal and less garden pathy than I'm able to pen at the moment.
-- Justin
On
>
> - give out authorization codes via the user-agent flow. We've
> implemented a variation of this based on HTML5 and window.postMessage.
>
Caveat: This will run you off-spec.
> - use a fixed callback URL for the user-agent flow. Make sure that
> fixed callback URL does not run random bits o
You can still use the access code (web server) flow within a JavaScript
application, just without a reliable client secret. The point of the
"implicit" flow was to save a roundtrip to the server for light clients
with limited lifespans, and it's a tradeoff between security, ease of
implementation,
The OpenID Connect folks have been using Simple Web Discovery, which is
as I understand it a rough translation of XRD into JSON, with a couple
of simplifying changes. (Mike, want to throw your hat in on this one?)
http://tools.ietf.org/html/draft-jones-simple-web-discovery-00
-- Justin
On Mon,
801 - 900 of 1006 matches
Mail list logo
