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 wrote:
> Hi Justin
>
>
> On 04/09/14 13:15, Richer, Justin P. wrote:
>> Neither of these are authentication (they don't tell
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 flow,
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 and
hi Hans
On Sep 4, 2014, at 3:15 PM, Hans Zandbelt 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 distinction can't be
> "regi
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 Bil
hi Bill
On Sep 4, 2014, at 2:52 PM, Bill Burke 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 a little
> eas
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 s
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 is
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 va
On Sep 4, 2014, at 2:22 PM, John Bradley 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 slippery to differ
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 inc
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
mailto:hzandb...@pingidentity.com>> wrote:
Maybe just to clarify my point: where did the client_id in the example that you
gave come from?
Hans.
O
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 ca
Inline
On Sep 4, 2014, at 11:30 AM, Frizz 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:
> (1) Client calls Bu
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
registration
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
registration
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 HTTP
hi Hans
On Sep 4, 2014, at 10:58 AM, Hans Zandbelt 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 indeed and a
> securit
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 mu
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 wrote:
> Classifying like this must also mean that consent should not be stored u
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 o
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
22 matches
Mail list logo
