benefits.
Thanks all,
--
Jim Manico
@Manicode
Secure Coding Education
> On Aug 28, 2023, at 8:15 AM, Jim Manico wrote:
>
> *applause*
>
> Sucks you need to explain yourself several times but this is very helpful for
> the community.
>
>>> On Aug 28, 2023
*applause*
Sucks you need to explain yourself several times but this is very helpful for
the community.
> On Aug 28, 2023, at 7:52 AM, Philippe De Ryck
> wrote:
>
> Responses inline.
>
>> Still, there is some initial incorrect point that makes the rest of the
>> discussion complicated, and
emain or even move to a MUST. Storing high powered access tokens in a browser is significantly insecure in the face of XSS which very (very) few applications control well, especially ones that are complex enough to need OAuth2.--Jim Manico@ManicodeOn Mar 9, 2023, at 3:30 AM, Warren Parad wrote:It
rent security
best practice guide here.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-19#section-2.2
So yes!
- Jim Manico
On 3/2/22 8:18 AM, Warren Parad wrote:
Is there a reason you wouldn't want to use the access token to access
these resources? That seems li
> That’s why cookies should be set with the __Host- prefix.
You can also set the domain of a cookie to actually be a host (subdomain). Does
that also prevent subdomains from clobbering root directory cookies?
PS: I realize this is close to off topic, my last comment on this.
- Jim Man
n policy rather than same-site.
— Neil
On 25 Sep 2021, at 18:20, Jim Manico wrote:
If someone has taken over a subdomain in the ways described, that
is not cross site request forgery since the attack is occurring from
within your site. It’s more likely XSS that allows for cookie
clobbering
subdomain. This is not
strictly CSRF nor are these problems protected from any other standard form of
CSRF defense.
CSRF is Cross Site attack where the attack is hosted on a different domain.
--
Jim Manico
> On Sep 25, 2021, at 1:07 AM, Dominick Baier wrote:
>
>
> In
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Jim Manico
Manicode Security
https://www.manicode.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Manico
On 3/1/21 9:59 AM, Vittorio Bertola wrote:
Il 01/03/2021 15:13 Jim Manico ha scritto:
How does OAuth harm privacy?
I think you are analyzing the matter at a different level.
If you start from a situation in which everyone is managing their own
online identity and credentials, and
ient needs to see
this in order to effectively communicate to the RS/AS provider. I do not
see this as a problem. The user is specifically allowing it.
Denis, please keep going. I am not a top tier expert I am still
learning. I would love to keep this conversation going.
Respectfully,
- Jim M
really look like and what the OAuth2
framework/protocol actually is.
I am not being combative or trying to hurt anyone when I say that I feel many
of the commenters here do not understand the details of OAuth2 and what it’s
for.
--
Jim Manico
@Manicode
> On Mar 1, 2021, at 6:10 AM, And
secure solutions
are built as opposed to the dumpster fire that OAuth solutions have become
today.
Regards,
--
Jim Manico
@Manicode
Secure Coding Education
> On Feb 24, 2021, at 12:48 AM, Phillip Hallam-Baker
> wrote:
>
>
> I am worried by the advice 'use OAUTH' but fo
aft-ietf-oauth-browser-based-apps-07#section-9.7>
On Wed, Dec 9, 2020 at 4:10 PM Jim Manico <mailto:j...@manicode.com>> wrote:
The basic theme from the web attacker community is:
1) XSS is a game over event to web clients. XSS can steal or abuse
(request forgery) toke
se
notify the sender immediately by e-mail and delete the message and any
file attachments from your computer. Thank you./
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Jim Manico
Manicode Security
https://www.manicode.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
s scope for influencing RTs and Ats (in particular, in the
context of SPAs) but that's additional semantic that isn’t defined today.
-Original Message-
From: OAuth On Behalf Of Jim Manico
Sent: Sunday, October 4, 2020 5:17 PM
To: Nicolas Mora
Cc: oauth@ietf.org
Subject: Re: [OAUTH-W
> In this model, considering that token revocations don't happen a lot...
Just a brief note, a secure piece of software makes the logout feature
prominent. Every logout event should trigger token revocation.
I’m mentioning this because a lot of OAuth solutions in the mobile space
literally igno
It does not make sense to use OAuth in most single party situations. These
single-party OAuth use cases are frequently a complete misuse of the framework.
I +1 the language “3rd party” in an effort to steer implementors in the right
direction.
--
Jim Manico
@Manicode
> On Aug 28, 2020, a
it could
be referenced or included in OAuth 2.1 depending on the relative
timing.
/Dick
ᐧ
On Thu, Jul 30, 2020 at 1:47 PM Jim Manico mailto:j...@manicode.com>> wrote:
I politely encourage the rules to be bent and to integrate
this basic b
barrier to entry.
--
Jim Manico
@Manicode
> On Jul 30, 2020, at 3:21 PM, Dick Hardt wrote:
>
>
> One of the constraints of the OAuth 2.1 document that aligned the WG was it
> would have no new features.
>
> I'd recommend a separate document for the cookie bearer token
hard in apps
with complex UI’s!
--
Jim Manico
@Manicode
> On Jul 30, 2020, at 1:13 PM, Warren Parad wrote:
>
>
>> Cookie storage of tokens does leave one open to CSRF attacks so it's
>> certainly a trade-off. But CSRF is much easier to defense against that XSS
&
ailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Jim Manico
Manicode Security
https://www.manicode.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
> We are not talking about ROPC mandating OAuth2, but about OAuth-2.1
> forbidding the user of ROPC.
Absolutely and this seems like a good thing. ROPC seems very close to a use
case that calls for OIDC instead of a OAuth2x token so I endorse the move.
--
Jim Manico
@Manicode
Secure
Forgive me if this question is late or poor context, but wouldn’t OIDC be a
better replacement for ROPC since it’s essentially a authentication flow?
What use case for ROPC mandates OAuth2 over OIDC?
--
Jim Manico
@Manicode
> On May 11, 2020, at 11:00 PM, Francis Pouatcha
> wrote:
>
It’s actually worse. Parameters in a URL leak over bookmarks, browser history,
logs everywhere, referrer headers...
One of the most primary rules of secure coding on the web is to never put
sensitive data in a URL for •any• verb, not just GET.
--
Jim Manico
@Manicode
Secure Coding Education
> I would argue TLS basically prevents leakage and not replay
Doesn’t token binding, which is esentially a TLS extension, prevent some forms
of token replay?
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On Nov 22, 2019, at 7:26 AM, Richard Backman, Annabelle
&g
I love you Neil.
--
Jim Manico
@Manicode
> On Oct 30, 2019, at 3:18 PM, Neil Madden wrote:
>
>
> If you can point out where I recommended disabling TLS or not bothering to
> strip headers from incoming requests, or anything else along those lines then
> please let me kn
imagine that something closer to XACML
would work.
--
Jim Manico
@Manicode
> On Apr 22, 2019, at 9:34 AM, Pedro Igor Silva wrote:
>
> Hi Torsten,
>
> Great article, thanks for sharing it.
>
> We have been working on a solution for fine-grained authorization using
>
least for DOM XSS) that will
arrive in the near future.
https://developers.google.com/web/updates/2019/02/trusted-types
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman
browsers. IE, Edge and
Safari iOS still have only partial support.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On Dec 9, 2018, at 9:23 AM, Filip Skokan wrote:
>
> As David suggested,
>
> it is easier to get rid of the code from a query using a referrer policy
ainfully low.
- Jim
On 12/7/18 5:27 PM, David Waite wrote:
>> On Dec 7, 2018, at 5:50 AM, Jim Manico wrote:
>
>> I still encourage developers who are not XSS guru’s to stick to cookie based
>> sessions or stateless artifacts to talk to the back end and keep OAuth
>&
/DOM_based_XSS_Prevention_Cheat_Sheet
Unpopularity yours,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On Dec 6, 2018, at 1:09 PM, Vittorio Bertocci
> wrote:
>
> Thank you Torsten.
> I think that a lot of the considerations below need to be tempered with
> concrete considerations
at Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Jim Manico
Manicode Security
https://www.manicode.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
work!
Aloha and Well Wishes,
--
Jim Manico
Manicode Security
https://www.manicode.com
On 11/19/18 4:04 PM, Hannes Tschofenig wrote:
> Hi all,
>
> The authors of the OAuth Security Topics draft came to the conclusion
> that it is not possible to adequately secure the implicit flo
I want to +1 this as well. This really got my attention as an impressive and
straightforward defense technique.
Jim
> On Nov 19, 2018, at 3:48 PM, Hans Zandbelt wrote:
>
> +1 to the suggestions that Vladimir raises; I've seen a fair number of
> requests in the field for exactly that
>
> Ha
present on XSS defense in-depth to the Oath standard body community if you
wish. It’s a lot more difficult to get right than most think.
Once you have XSS, dang. Might as well just stick unsigned AT’s in URL’s.
Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On May
longer be effective or
active when used in a different client.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On May 18, 2018, at 1:38 PM, Neil Madden wrote:
>
> I might be missing something here, but aren’t bound tokens exactly as
> vulnerable to the XSS
best in the face
of XSS.
Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On May 18, 2018, at 12:53 PM, Brock Allen wrote:
>
> Fair enough, and I'm happy that this discussion has started.
>
> For now, IMO, CSP is a big help in protecting these
rge requests
through a victims browser, a much more common red team attack than trying to
steal a cookie.
And XSS resistant apps are illusive. For example .NET is missing core controls
around XSS defense like a well maintained HTML sanitizer for HTML input.
--
Jim Manico
@Manicode
Secure Cod
This is really fantastic news. Thank you for sharing that John. I’m a lot more
optimistic about timely adoption.
Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On May 18, 2018, at 12:53 PM, John Bradley wrote:
>
> Token binding was just approved by the
> important, before any new recommendation.
Well said. It looks to be the only secure workflow for browser based apps. Love
it how passwords are kept away from RP’s and high powered tokens are not stored
in the browser.
Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-38
If you plan on adding these web layer security suggestions into the OAuth
standard I can think of 100-200 more requirements to add. I thought “do web
security right” was an implied recommendation?
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On Mar 20, 2018, at 5:37
ty happening behind
> the scenes?
>
> -- Neil
>
>> On 20 Sep 2017, at 02:31, Jim Manico wrote:
>>
>> Not always, Bill. There is a new standard called "same site cookies" or
>> "first party cookies" that allows you to programma
g.
I also asked the author of this standard for additional commentary, I'll get
back to you.
--
Jim Manico
@Manicode
> On Sep 20, 2017, at 1:21 PM, Neil Madden wrote:
>
> Is this growing in support? It seems like a good idea, but when I reviewed it
> recently the draft had exp
Not always, Bill. There is a new standard called "same site cookies" or "first
party cookies" that allows you to programmatically remove this risk in some
modern browsers, it's worth reviewing.
https://tools.ietf.org/html/draft-west-first-party-cookies-07
It's live in Chrome and Opera and will
One of the reasons I see so many security folk discouraging implicit in web
applications (like your Angular scenario) is because even though refresh tokens
and similar require authentication, how do you store that info securely in a
browser? One XSS and it's http://m.youtube.com/watch?v=dsx2vdn7
t; the code anyway (and
> then immediately revoke the token, maybe), or you're probably making
> things worse (if you're worried of leaking 5min one-time codes,
> particularly when that code cannot be used without a client_secret
> and/or PKCE code_verifier)
>
> Disclai
in modern browsers, which is one reason why
many security folks recommend against the implicit grant type. (I'll double
check on this one)
Respectfully,
--
Jim Manico
@Manicode
> On Aug 12, 2017, at 11:43 AM, John Bradley wrote:
>
> From a interoperability perspective accepting both
POSTs to its redirect_uri? If so, what would be the
>> considerations for a server choosing between GET and POST?
>>
>> Best,
>>
>> Josh
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Jim Manico
Manicode Security
https://www.manicode.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I would take it a step further. GET's leak parameters even over HTTPS. I advise
all GET based OAuth communication to be switched to POST, a much more security
centric verb.
Aloha,
--
Jim Manico
> On Aug 11, 2017, at 3:08 PM, Josh Mandel wrote:
>
> Fixing my "with this
ength of compressed+encrypted data leaks information about
> cleartext.
>
> Thanks,
> Yaron
>
> On 29/07/17 21:32, Jim Manico wrote:
>> Yaron,
>>
>> As a developer, I can think of many scenarios where the attacker
>> controls some of the plaintext yet I still n
Yaron,
As a developer, I can think of many scenarios where the attacker controls some
of the plaintext yet I still need encryption services of some kind. What are
the proper crypto controls that allow developers to do this safely? I think
that's the better question right now.
Aloha,
-
I support adoption of this document.
Aloha, Jim
On 7/20/17 2:37 AM, Rifaat Shekh-Yusef wrote:
> All,
>
> We would like to get a confirmation on the mailing list for the
> adoption of the *JSON Web Token Best Current Practices* as a WG document
> https://datatracker.ietf.org/doc/draft-sheffer-oau
I'd love to attend.
1) Can you handle remote participants?
2) Any chance you want to move this to Hawaii? I can host the work space.
Seriously.
Aloha,
--
Jim Manico
@Manicode
> On Apr 20, 2017, at 7:42 PM, Torsten Lodderstedt
> wrote:
>
> Hi all,
>
> I'm p
From a security POV please force HTTPS as we see in 5.2.1. The only performance
problem with HTTPS is that it's not used enough. There is no good reason for a
security framework to support HTTP.
Aloha,
Jim
> On Mar 24, 2017, at 9:15 AM, Dave Tonge wrote:
>
> Hi Nat and John
>
> I have some q
ion in OAuth:
> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-02
>
> Application in OpenID Connect:
> http://openid.net/specs/openid-connect-token-bound-authentication-1_0.html
>
>
>
>
> On Fri, Mar 17, 2017 at 9:09 AM, Jim Manico <mailto:j...@manicode.c
Hello OAuthers,
I'm trying to get my head around token binding beyond the RFC. Are there any
presentations or other media on token binding that any of you are aware of? My
google-fu is coming up empty.
Thanks and Aloha,
- Jim
___
OAuth mailing list
OA
head. Does
anyone here with more experience care to assist in proposing a SPA-OAuth RFC?
I'd be happy to help with the grunt work. This is one of the main areas of
OAuth where answers are fractured and I'd love to help push more clarity here.
Aloha,
--
Jim Manico
@Manicode
Secure Codi
l turmoil over the usage of
>> implicit grant for ua-based apps. The webapp case is well
>> understood and the WG has work in progress to define best
>> practices for native apps. Having one for ua-based apps would be
>> HUGELY beneficial
>>
>>
&g
ogress to define best practices for native
>> apps. Having one for ua-based apps would be HUGELY beneficial
>>
>>
>>
>> On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico > <mailto:j...@manicode.com>> wrote:
>>
>> Thank you to those answering my qu
;
> 1) access tokens would be in the browser history
>
> 2) short lived access tokens (seconds or minutes) would require a
> browser redirect
>
> I'd be really curious to hear other's thoughts though.
>
> [1] http://keycloak.org
>
>
>
>
>
&
tions?*
Aloha,
--
Jim Manico
Manicode Security
https://www.manicode.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Jim Manico
Manicode Security
https://www.manicode.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Riyadh,
You best off reading the Dropbox OAuth guide and asking Dropbox support with
your questions. Each provider does OAuth a little bit differently.
https://www.dropbox.com/developers/reference/oauth-guide
Respectfully,
--
Jim Manico
@Manicode
> On Dec 22, 2016, at 1:49 AM, Riyadh Biy
configured HTTPS, POST and other verbs, and data
being the body of the request, not in the action of a form. Fair?
(And sorry, I missed this one the first time around)
Aloha, Jim
On 12/9/16 8:54 PM, Jim Manico wrote:
> Torsten,
>
> The
> https://datatracker.ietf.org/doc/draft-lodderstedt-oa
URIs/URLs and I have seen some solutions that break the
"standard" and POST/PUT/PATCH when they can, keeping tokens out of POST
actions, URL's and similar. Is this worth discussing?
Thank you again for this very important and well written document.
Aloha from Hawaii,
--
Dude. You're freaking awesome. Thanks for this insight.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On Nov 24, 2016, at 7:48 AM, Samuel Erdtman wrote:
>
> +1 on providing guidance.
>
>
>> On Wed, Nov 16, 2016 at 12:08 AM, Brian Campbell
&g
ed a
>> certificate from a trusted CA, and then services that the client
>> talks to being told to trust that CA and also assign the CN/DN of
>> the cert a set of privileges. What I *haven’t* seen is a client
>> being issued multiple certificates to talk to
uot; so I can selectively manage each access separately, but I
understand where you are coming from and it makes sense.
Thanks for taking the time to respectfully explain your perspective and
provide me with a little education. :)
ALOHA,
Jim Manico
On 11/3/16 12:32 PM, Justin Richer wrote:
> J
Thanks Justin. I use several security intel services and they all have
different cert delivery mechanisms for mutual TLS. It's •rare• for services to
let clients choose certs, they are usually assigned to users by each service
from my experience.
Aloha,
--
Jim Manico
@Manicode
Secure C
uggest a separate key/signature for each service.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On Nov 3, 2016, at 8:41 AM, Justin Richer wrote:
>
> I agree that the client_id is unlikely to be found inside the certificate
> itself. The client_id is issued by
st regards,
>> Maciej Kwidziński
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing lis
should be improved in implicit grants is removing
> secrets from URL (fragment). That could be done as I've shown in the
> previous discussions.
>
>
>
> *From:* Jim Manico
> *To:* John Bra
;
> I don’t know that there is a perfect solution for bearer tokens, but
> documenting the tradeoffs may be useful.
>
> John B.
>
>> On Sep 8, 2016, at 6:07 PM, Jim Manico > <mailto:j...@manicode.com>> wrote:
>>
>> +1 I think that's a very fair
the value of HTTPOnly will continue diminishing, while
> the value of good cross-domain policies will increase. Just my opinion
> coming from my experience. I don't have big (or small) data available
> to confirm that.
>
>
> ----------
s enforce HTTPOnly and now - I can't.
>
> Thanks,
> Oleg.
>
> ------------
> *From:* Jim Manico
> *To:* Adam Lewis
> *Cc:* OAuth WG
> *Sent:* Thursday, September 8, 2016 10:45 AM
> *Subject:* Re: [OAUTH-WG] best practices for implicit gra
There is also a huge body
of work underway to make secure cookies even more so.
I'm not sure how this translates to native apps.
--
Jim Manico
@Manicode
> On Sep 8, 2016, at 3:02 AM, Adam Lewis
> wrote:
>
> Hi,
>
> The WG is currently putting together best practic
t;strong authentication" like mutual TLS or similar be a better default
standard? The OAuth 2 threat model makes this exact recommendation.
Respectfully,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On Jul 28, 2016, at 4:25 PM, Justin Richer wrote:
>
> These ar
Please forgive me if this comment is out of order or inappropriate in any way...
...but why is HTTP Basic even being discussed in 2016? It has horrific security
properties at multiple levels; shouldn't we at least move to HTTP Digest if not
something stronger?
Regards.
--
Jim Manico
@Man
HTTP POST requests are also a lot more difficult to cache server side compared
to URI's which are easier to cache. I'm likely not explaining this well, but I
believe it's a webscale concern.
--
Jim Manico
@Manicode
> On Jul 1, 2016, at 11:01 PM, Oleg Gryb wrote:
>
>
y are
explicitly cleared this makes fragment encoding less safe than it was when
originally specified"
Again, I'm new here but I'm grateful for this conversation.
Aloha,
--
Jim Manico
@Manicode
> On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote:
>
> We've discussed
HTTPS.
4) If you really must submit sensitive data over GET , consider
JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level
confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com
On 6/27/16 9:30 PM, Liyu Yi wrote:
>
> While we are w
topic.
If anyone sees any flaws in these or otherwise would like to help make
these better, please drop me a line. I serve on the OWASP board.
Aloha, Jim Manico
On 5/11/16 11:59 AM, Nat Sakimura wrote:
> Agreed. Also, pointing to OWASP guide or something for CSRF token may
> be useful.
&g
- not a standard - which
can be implemented many ways, of course.
Aloha,
--
Jim Manico
@Manicode
> On Feb 15, 2016, at 5:34 PM, Phil Hunt (IDM) wrote:
>
> In older systems, time based logout is all you have if you aren't assessing
> risk.
>
> I would think over time w
ndary, not prompting the
user for re-authentication credentials is unacceptable in those environments.
I may be jumping in out of context, but fair?
--
Jim Manico
@Manicode
+1 (808) 652-3805
> On Feb 15, 2016, at 3:36 PM, William Denniss wrote:
>
> We return 'amr' claims
ssible.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On Nov 4, 2015, at 8:01 AM, Sergey Beryozkin wrote:
>
> Hi All
>
> I'm having a discussion with my colleagues on the pros and cons of sharing a
> client_id.
>
> For example, say we have N n
Ok then it looks like the name is good as is. :)
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On Oct 15, 2015, at 6:52 AM, Nat Sakimura wrote:
>
> That’s true, but RFC6749 uses the term Authorization request to mean the
> request sent to the authorizat
This seems like a reasonable approach. Isn't the whole idea of the auth
server/resource server separation in OAuth 2.0 so that one auth server can
govern multiple resource servers?
--
Jim Manico
@Manicode
> On Oct 13, 2015, at 6:13 AM, Ofer Nave wrote:
>
> I know the OAuth 2
But its all authorization, even the token request
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On Oct 9, 2015, at 5:23 PM, Nat Sakimura wrote:
>
> The reason for saying authorization request is that there are two types of
> requests in RFC6749; authoriza
The word authorization is implied by OAuth, consider "OAuth 2.0 JWT Request".
--
Jim Manico
@Manicode
(808) 652-3805
> On Oct 9, 2015, at 3:43 AM, Nat Sakimura wrote:
>
> Hi OAuthers:
>
> One of the to do for https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-0
I stand corrected, the RFC does give specific time recommendations such
as 10 minutes authorization code recommendation here
https://tools.ietf.org/html/rfc6749#section-4.1.2 but I think my overall
point is still valid. :)
Aloha,
Jim
On 8/28/15 11:36 AM, Jim Manico wrote:
Again, I would
risk,
social media, banking, enterprise, etc) as opposed to one recommendation.
With respect,
Jim Manico
On 8/28/15 10:41 AM, John Bradley wrote:
I would use a 5 min AT and roll the refresh token per
https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if
that is what you want for
This is all contextual to the application. In some situations I want to
immediately force re-authentication for all transactions above X$ such
as banking applications. In some situations I want a permanent refresh
token, like for Twitter like social applications. etc...etc...
- Jim Manico
this list update StackOverflow if
necessary?
Aloha,
--
Jim Manico
@Manicode
(808) 652-3805
> On Aug 23, 2015, at 11:41 PM, Donghwan Kim wrote:
>
> Hi,
>
> According to Figure 2 from http://tools.ietf.org/html/rfc6749#section-1.5,
> refresh token can be used to refresh an ex
93 matches
Mail list logo
