Observe the state of the AZA protocol interop. AZA leverages OpenID Connect to provide a standards-based approach for SSO to multiple native applications.

1. Na#ve
Single
SignOn
Interop
Demonstra#on
Cloud
Iden#ty
Summit
2013
1

2. Mo#va#on
• Enterprise
employees
use
mul#ple
applica#ons
(combo
of
web
&
na#ve)
in
their
jobs
• Applica#ons
both
hosted
on-­‐prem
&
SaaS
• Current
reality
is
that
an
SSO
experience
limited
to
the
browser
apps
• But
na#ve
applica#ons
becoming
more
and
more
prevalent
• Poten#ally
significant
usability
burden
for
employees

3. Default
OAuth
paNern
for
na#ve
applica#ons
• Employee
authen#ca#on/authorizes
each
applica#on
individually
• Authoriza#on
manifested
as
the
issuance
of
an
OAuth
token
to
each
na#ve
app
–
this
presented
on
subsequent
API
calls
to
corresponding
server
• Employee
interacts
with
each
OAuth
AS
(corresponding
to
each
API)
to
obtain
an
OAuth
token

4. Implica#ons
of
default
paNern
• Employee
bears
burden
of
authen#ca#ng/
authorizing
each
na#ve
applica#on
separately
• Even
if
done
infrequently,
may
be
unacceptable
• Each
SaaS
must
directly
support
OAuth
(running
an
Authoriza#on
Server)
• Enterprise
distanced
from
employee's
use
of
na#ve
applica#ons

5. Na#ve
App
SSO
Alterna#ve
• An
employee
is
able
to
collec#vely
authorize
each
na#ve
applica#on
on
device
in
one
step
• Rather
than
each
applica#on
individually
obtaining
OAuth
tokens
for
itself
the
tokens
are
obtained
on
behalf
of
those
na#ve
applica#ons
by
a
dedicated
'authoriza#on
agent'
(AZA)
• Employee
authorizes
the
AZA,
which
then
proceeds
to
obtain
for
other
applica#ons
the
necessary
access
tokens
• Once
handed
the
tokens,
na#ve
applica#ons
use
them
as
normal
on
API
calls
• For
user,
enables
an
SSO
experience
for
na#ve
applica#ons

6. AZA
Alterna#ve
6
Enterprise
SaaS
Device
Browser
Na#ve
SaaS
SaaS2
Na#ve
SaaS2
AS
AS
Client
Client
AZA

7. AZA
Alterna#ve
7
Enterprise
SaaS
Device
Browser
Na#ve
SaaS
SaaS2
Na#ve
SaaS2
AS
AS
Client
Client
AZA
AS

8. SaaS
AZA
Alterna#ve
8
Enterprise
Device
Browser
AZA
AS
Browser
Na#ve
SaaS
AZA
Na#ve
SaaS2
SaaS2

9. Alterna#ve
9
Enterprise
Device
Browser
Na#ve
SaaS
SaaS
AZA
Na#ve
SaaS2
SaaS2
AS

10. Implica#ons
1. Na#ve
apps
must
be
able
to
request
access
tokens
of
a
local
AZA
2. AZA
must
be
able
to
request
access
tokens
on
behalf
of
another
na#ve
applica#on
3. AZA
must
be
able
to
hand
over
access
tokens
to
na#ve
applica#on
4. RS
must
be
able
to
validate
access
tokens
(poten#ally
issued
by
a
remote
AS)
10

11. Standardiza#on
• Mul#ple
pieces
(from
different
providers)
implies
need
for
standards
• A
number
of
industry
players
working
to
profile/extend
OpenID
Connect
for
the
AZA<-­‐
>AS
interac#on
– New
WG
being
formed
in
OpenID
Founda#on
• Related
but
separate
effort
to
standardize
App<-­‐>
AZA
messaging
emerging

12. Interoperability
• We
are
demonstra#ng
interoperability
between
different
AZAs,
OAuth
ASs,
na#ve
applica#ons,
and
OAuth
RSs
• The
AZA<-­‐>AS
protocol
is
based
on
OAuth
(not
the
eventual
OIDC-­‐based
standard)
• MobileIron
&
Ping
also
implemented
a
back-­‐
channel
authoriza#on
query
interface
12

13. Interop
Par#cipants
13

14. Interop
Scenarios
14
AZA
AS
AZA
AZA
AS