Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Vittorio Bertocci <[e-mail]>]

David, I think you are hitting on something really important here.
For non-identity experts, the SPA umbrella covers every app updating the UX
via JS instead of postbacks- regardless of the underlying topology. Does
the app have its own backend and that backend has no other clients? Does it
call its own backend AND other APIs? Does it call 3rd party APIs only? Is
the current set of requirement stable for the foreseeable future, or will
the app evolve to change its use case?
Those are all questions that can be dismissed by advising the developer to
use the most generic approach possible, e.g. getting tokens in the browser,
however that comes at a complexity price that might be unnecessary if in
their particular case just using cookies against their own backed (an
extremely common setup, in my experience) would be enough. Even when
wrapped in SDKs, that complexity is not entirely free- think ITP and the
like.
Per the above, just giving a blanket advice for all SPA subtypes might not
be the simplest solution for a large number of developers.

The question I don't have a good answer for is- how do we help developers
with no identity experience (and no interest in acquiring it) to determine
in what pattern they fall into, and pick the guidance relevant to their
scenario? Maybe by formally enumerating those topologies and giving them
names? Do you guys have ideas?

On Wed, Dec 5, 2018 at 9:29 AM David Waite <[e-mail]>
wrote:

>
>
> > On Dec 5, 2018, at 5:16 AM, Torsten Lodderstedt <[e-mail]>
> wrote:
> >
> > Hi Tomek,
> >
> >> Am 04.12.2018 um 19:03 schrieb Tomek Stojecki <[e-mail]>:
> >>
> >> Thanks Torsten!
> >> So if I am putting myself in the shoes of somebody who sets out to do
> that - switch an existing SPA client (no backend)
> >
> > I would like to ask you a question: how many SPAs w/o a backend have you
> seen in your projects?
>
> Pivoting to apps with local domain business logic (aka a backend):
>
> Setup - the developer is building a browser-targeted app and at least one
> mobile app - their backend would likely be identical across all three.
>
> In that case, would they want client access to that backend to be secured
> with access tokens? Or should that backend to be the client to the AS, and
> communication from the javascript to the backend be secured with some
> non-OAuth method like cookies or API keys?
>
> I push for OAuth in most of these cases, unless their strategy for mobile
> apps is to “wrap” the browser code and content into a native app - in which
> case more flexible access to that backend can be deferred if desired until
> there is stronger business need.
>
> -DW
>
>