I think this advice isn't a bad idea, though it's of course up to the AS what
an untrusted client really is. In practice, this is something that was
registered by a non-sysadmin type person, either a dynamically registered
client or something available through self-service registration of some
Classifying like this must also mean that consent should not be stored
until the client is considered (admin) trusted, and admin policy would
interfere with user policy.
IMHO the security consideration would apply only to dynamically
registered clients where registration is unrestricted; any
Hi Hans,
I really fail to see how this can be addressed at registration time for cases
where registration is unrestricted (namely all the big Providers)
regards
antonio
On Sep 4, 2014, at 9:47 AM, Hans Zandbelt hzandb...@pingidentity.com wrote:
Classifying like this must also mean that
Agreed, I see you point about the big providers using exactly the
unrestricted flow for which the trust model (by definition) is out of
scope of the spec. This may be the reason for the implemented behavior
indeed and a security consideration is a good idea for other
deployments; there's not
hi Hans
On Sep 4, 2014, at 10:58 AM, Hans Zandbelt hzandb...@pingidentity.com wrote:
Agreed, I see you point about the big providers using exactly the
unrestricted flow for which the trust model (by definition) is out of scope
of the spec. This may be the reason for the implemented behavior
Hello there,
I have a question regarding Authentication:
The following two scenarios, are they typical use cases for OAuth? Or
OpenId-Connect? Or something completely different?
Flow (A) would be like this:
(1) Client calls Business Logic Server
(2) Server detects there’s no Access Token in
yes, you are right about the unrestricted client use case; I just got
caught by the fact that you were talking about *unrestricted* client
registration all the time (standards-based or not) which deserves extra
caution whereas Google (and the spec) also provides *restricted* client
Maybe just to clarify my point: where did the client_id in the example
that you gave come from?
Hans.
On 9/4/14, 1:58 PM, Hans Zandbelt wrote:
yes, you are right about the unrestricted client use case; I just got
caught by the fact that you were talking about *unrestricted* client
Inline
On Sep 4, 2014, at 11:30 AM, Frizz frizzthe...@googlemail.com wrote:
Hello there,
I have a question regarding Authentication:
The following two scenarios, are they typical use cases for OAuth? Or
OpenId-Connect? Or something completely different?
Flow (A) would be like this:
Neither of these are authentication (they don't tell the client or business
logic server who the user is or if they're still there), they're authorization
and they're both well within the scope of OAuth.
The first one is a redirect flow, that actually works (in OAuth) like this:
1) Clients
I registered via the Google Developers Console [0] :)
[0] https://console.developers.google.com/project
On Sep 4, 2014, at 2:09 PM, Hans Zandbelt
hzandb...@pingidentity.commailto:hzandb...@pingidentity.com wrote:
Maybe just to clarify my point: where did the client_id in the example that you
Registration requiring a valid email address is not sufficient to stop a bad
person from registering a client that appears to be perfectly legitimate but is
later used as a redirect.
So it is a bit slippery to differentiate good from bad.
In general clearing the referrer and fragment from
On Sep 4, 2014, at 2:22 PM, John Bradley ve7...@ve7jtb.com wrote:
Registration requiring a valid email address is not sufficient to stop a
bad person from registering a client that appears to be perfectly
legitimate but is later used as a redirect.
totally agree!
So it is a bit
exactly, but my point would be that the attacker needs to have an
relationship/account with the OP; this is where the approval is and I
agree with Antonio/you that that is tricky for consumer ASs and deserves
a warning
Hans.
On 9/4/14, 2:22 PM, John Bradley wrote:
Registration requiring a
In a enterprise case likely there is some trusted relationship.
In the Web 2.0 API economy case there is a tension between providers wanting
the maximum number of users and validating the developer registering the client.
Often having a email someplace is sufficient to register a client. That
FWIW, Antonio convinced me and I'm going to change this in our IDM
project. Thanks Antonio. What convinced me was that the user is
probably expecting a login screen. Since there is this expectation, it
might make it a little easier for the attacker to convince the user that
a spoofed login
hi Bill
On Sep 4, 2014, at 2:52 PM, Bill Burke bbu...@redhat.com wrote:
FWIW, Antonio convinced me and I'm going to change this in our IDM project.
Thanks Antonio. What convinced me was that the user is probably expecting a
login screen. Since there is this expectation, it might make it
I am convinced about the issue in the use case Antonio provided but I
hope not to close the door on returning errors to known and trusted
clients. Not sure anymore if that's possible though because the
distinction can't be registered...
Hans.
On 9/4/14, 3:01 PM, Antonio Sanso wrote:
hi Bill
hi Hans
On Sep 4, 2014, at 3:15 PM, Hans Zandbelt hzandb...@pingidentity.com wrote:
I am convinced about the issue in the use case Antonio provided but I hope
not to close the door on returning errors to known and trusted clients. Not
sure anymore if that's possible though because the
The distinction can be made, and it's AS policy. Sometimes (like in our case)
the AS distinguishes between client registered by an administrator vs. an end
user vs. something dynamic (no user involved). And in the latter cases, the AS
can still figure out how long something's been registered
Hi Justin
On 04/09/14 13:15, Richer, Justin P. wrote:
Neither of these are authentication (they don't tell the client or business
logic server who the user is or if they're still there), they're authorization
and they're both well within the scope of OAuth.
The first one is a redirect
As John points out, that could be either resource owner or client credentials
flow, depending on the use case.
-- Justin
On Sep 4, 2014, at 11:43 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
Hi Justin
On 04/09/14 13:15, Richer, Justin P. wrote:
Neither of these are authentication
22 matches
Mail list logo
