From what I have seen deployed, there are four common flows for registration.
1 2 developer uses a tool to register a client ID and place that in the client
code for deployment of a native App that is distributed via an app store for a
3rd party API. The developer may later need to make change
John,
Thanks for jumping in.
1. I do buy the implied argument that some client credential types do expire
(eg. bearer assertions). Therefore the expiry issue has to be dealt with. I
would prefer to handle this by allowing an exception whereby expired assertions
could be used to re-register (
Phil,
That is true.
All I am saying is the client may use the client_credential access token to
access groups of authorizations which have been granted based on the client
grant request and thus does have access to resources. Your initial post
said the client_credential grant cannot be used to
I’m saying that we issue an access token granting access to the registration
state for the client and a separate client_id (and sometimes client_secret)
used for accessing the Authorization Server. The first is used by the party
writing/registering the client. The second is used by the client.
Yes redirect URI matching is a problem. In Connect we mandate an exact match
because people are really bad at securing open relays.Trying to pattern
match the redirect also allows an attacker to circumvent the fragment
processing of the browser and generally increase the possible attack sur
Hi *,
I was wondering what you thing about the second "issue" described (the "Lassie
come home").
I have encountered lately in one enterprise installation and I think is fairly
easy to make it wrong as well.
Regards
Antonio
On May 17, 2013, at 5:46 PM, John Bradley wrote:
> The implicit fl
That is incorrect. A client grant request still results in a separate access
token issued.
Phil
On 2013-05-17, at 11:53, Donald F Coffin wrote:
> The statement "Keep in mind that client credential is only used with the
> token endpoint over TLS connection. It is NOT used to access resources
>
The statement "Keep in mind that client credential is only used with the
token endpoint over TLS connection. It is NOT used to access resources
directly." is incorrect. Section 4.4 of RFC 6749 states:
The client can request an access token using only its client
credentials (or other suppo
1 No reasonable security profile is going to let you use the same symmetric
password over long time periods. It will be brute forced given enough time.
The rotation time will depend on entropy and the rate an attacker can submit
attempts.I would expect profiles to look at SP-800-63 for gu
Justin,
Your reason was you copied connect. Ok. I was looking for a technical reason.
A security reason.
BTW. Mike Jones says expiry wasn't the reason.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-05-17, at 9:01 AM, Justin Richer wrote:
> The separation betw
The separation between these two is necessary: Not all clients have
client_secret, and you want the lifecycle/management of the registration
to be protected. This is what the registration access token was made
for. In older versions of Connect's registration, the client_secret was
forced on all
The implicit flow is secure in Connect, but we added a number of things to make
it so.
The reason to have it in OAuth 2 is for clients in the browser there are use
cases for that and it allows the browser to receive and extract the token
without passing it to a web server backend.
Used as inten
One wonders that - if in hindsight - the implicit flow was a mistake to include
in the framework. Yes it saves a single round trip for use cases where the
tokens are exposed to the UA, but it's not clear that optimization is worth the
security headaches that are going to be caused down the road
Or, are you saying reg access token is a signed assertion echoing back the
registration?
I have to think about that. Still don't see the value since there should be
only one registration per client cred.
To me the client token can also be the registration more easily with less
complexity.
P
14 matches
Mail list logo
