On Mon, Dec 3, 2018 at 4:18 AM David Waite
wrote:
> If (as Hans proposed) there was a mechanism for javascript to get access
> tokens to interact with protected resources in lieu of the client, there
> could be BCP around managing that (which would likely also overlap with a
> genuine javascript-
Agreed, if the BCP is meant to describe javascript behavior for best practices
as respect to being an OAuth client, I’m unsure what would belong in this
document for javascript which is instead interacting over non-standard
mechanisms with an OAuth client.
Instead, it would be generalized brow
You may be placing undue confidence in that gateway acting as a confidential
client but having no real security of its own and which could be easily duped.
Phil
> On Dec 2, 2018, at 3:43 PM, Aaron Parecki wrote:
>
> In this type of deployment, as far as OAuth is concerned, isn't the backend
In this type of deployment, as far as OAuth is concerned, isn't the backend
web server a confidential client? Is there even anything unique to this
situation as far as OAuth security goes?
I wouldn't have expected an Angular app that talks to its own server
backend that's managing OAuth credential
I assume via the session context, carried
as cookie, token or part of the URL.
> Am 02.12.2018 um 12:54 schrieb Rob Otto :
>
> Apologies if I'm being dim (it wouldn't be the first time!) but how, in this
> scenario, do we identify the browser client and authenticate it to the
> backend, to ass
Apologies if I'm being dim (it wouldn't be the first time!) but how, in
this scenario, do we identify the browser client and authenticate it to the
backend, to associate it with the correct token(s)?
Cheers (and really interesting discussion so far)
Rob
On Sun, 2 Dec 2018 at 07:31, Torsten Lodde
