►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
OpenID Connect as SSO Solution: Strengths and Weaknesses - Álvaro Iradier, Sysdig
OpenID Connect (OIDC), an identity layer on top of OAuth2 protocol, makes user login easier and allows for a seamless SSO experience between multiple tools and services by delegating authentication to a trusted Identity Provider (Authorization Server). The concept is quite appealing at first sight. But different implementations and lack of agreement, both on the client applications and on the Authorization Servers, can ruin your trip. In this talk we will explain the basic concepts of OIDC, how it works, how it compares to other Federated Authentication systems like SAML, and some integration examples like Harbor or Kubernetes. Then we talk about some common issues that are still rough edges, like the user onboarding and the roles and group management. Finally, we will see how we can make some non-OIDC aware applications work with OIDC by delegating authentication to an Nginx proxy.
https://sched.co/Zeka
A
Hello,
I
am
alvaradiere
from
cystic.
Thank
you
for
assisting
to
this
talk
where
I'm
gonna
tell
you
about
my
experience,
while
implementing
open8d
connect
as
a
single
cylon
solution
in
complex
environments,
so
the
agenda
for
this
talk
will
be,
will
be
saying:
single,
sign-on
basics.
Let's
see
some
concepts,
then
what
is
open
id
connect?
We
will
see
some
typical
flow
examples.
A
A
A
So
what
does
single
sign-on
mean?
It's
a
very
broad
concept.
One
definition
could
be
the
one
in
the
slide,
so
allow
users
use
a
single
set
of
login
credentials
for
multiple
applications
which
can
be
related,
but
they
are
usually
independent.
Why?
Because
users
have
to
remember
less
password
and
no
need
to
re-enter
them
of
every
application
for
security.
You
lessen
the
chances
of
fixing
and
reduce
password
fatigue
and
also
reduce
password
issues
for
id
help
desk,
and
why
not?
Well,
there
is
a
higher
risk
for
response
credentials.
A
If
your
expenses
are
exposed,
all
the
applications
are
exposed.
So
you
should
increase
the
focus
on
protection,
for
example
using
multi-factor
authentication
and
also
you
convert.
You
turn
them
a
single
authentication
into
a
single
point
of
failure.
So,
if
it
fails
all
your
applications
will
fail
well
and
what
is
open
id
connect?
Well,
basically,
it
is
an
identity
layer
on
top
of
2.0
protocol
to
verify
identity
delegated
to
an
utilization
server,
so
it
allows
you
to
obtain
end
user
basic
profile,
information
in
an
interoperable
rest,
json
manner
compatible
with
web
javascript,
mobile
apps,
etc.
A
Basically,
it
lets
the
application
site
developers
authenticate
users
without
taking
on
the
responsibility
of
storing
and
managing
the
passwords
in
the
face
of
an
internet
that
is
well
populated.
With
people
trying
to
compromise
your
users
account
for
their
own
game.
The
openid
provider
can
handle
the
users
and
passwords
and
it
can
delegate
to
directory
services,
or
it
can
act
as
a
half
of
other
providers.
A
Let
them
be
open,
id
saml,
etc.
Example.
Open
id
providers
are
google,
sign-in,
microsoft
and
many
others.
Let's
also
introduce
some
open-ended
terminology
like
the
op,
the
open
id
provider,
which
is
the
server
that
performs
the
authentication
as
a
service,
sometimes
also
called
idp
identity
provider
and
the
relying
party
rp
or
simply
the
client
which
outsources
the
user
authentication
to
an
op.
Don't
confuse
the
client,
the
reliant
party
with
the
user,
the
reliant
party
or
client
uses
the
op
to
authenticate
the
user.
A
So
oidc
works
by
a
set
of
interactions
between
the
user,
the
user
agent,
that
is
the
browser
and
the
server
of
backend
and
the
openid
provider.
This
is
what
we
define
as
a
flow.
It
works
on
top
of
ol2.
So
if
you
are
familiar
with
it,
you
might
already
know
there
are
different
flows.
Why
this
in
the
slide
is
the
authorization
code
run
flow
where
the
client
is
registered
in
the
openid
provider
and
it
can
safely
store
and
keep
a
client
id
and
client
secret,
which
is
used
to
authenticate
the
client
with
the
provider?
A
This
flow
is
typically
used
by
web
applications
where
the
client
is
a
backend
server.
Let's
explain
it
step
by
step
and
I'll
try
to
be
brief
and
skip
some
details.
As
I
expect
some
of
you
are
already
familiar
so
first,
the
interaction
is
just
between
the
user
and
the
website.
Through
the
browser,
the
user
opens
a
site.
The
backend
sends
some
html
rendered
by
the
browser.
The
user
is
not
logged
in
so
it
clicks
the
login
using
openid
connect
button,
for
example,
using
google
as
an
opening
provider.
A
In
this
part
of
the
flow,
the
user
interacts
with
the
open
id
provider
to
get
authenticated.
The
redirection
causes
a
get
request
to
the
authorization
point
of
the
penalty
provider
and
includes
several
mandatory
parameters.
The
response
type
code
tells
the
provider
to
reply
with
an
authorization
code
via
a
callback.
The
redirect
uri
is
the
url
of
the
callback
where
the
utilization
code
will
be
sent.
A
The
client
id
identifies
the
client
which
must
be
previously
registered
in
the
provider,
including
a
list
of
authorized
callback
urls
and
the
scope
parameter
must
always
include
at
least
the
value
open
id.
There
are
other
parameters
like
state
dots
to
prevent
cross-site
request,
forgery,
replay
attacks
and
scope
can
include
email
profile
and
others
to
get
additional
user
information.
A
A
The
openid
provider
might
also
ask
the
user
to
keep
the
consent
to
access
its
identity
information
to
the
client
application.
This
is
the
typical
confirmation
dialog
to
allow
application
whatever
to
access
your
personal
information.
If
everything
is
okay,
the
web
server,
the
backend
now
receives
the
authorization
code
as
a
get
callback
request.
The
state
parameter
is
also
included,
so
it
can
be
verified.
A
Now-
and
this
is
the
characteristic
feature
of
the
utilization
grant
code
flow-
the
packet
now
talks
directly
to
the
op
to
exchange
the
receive
code.
It
sends
a
post
request
to
the
op
and
includes
in
class
the
code
received
in
the
callback,
the
client
id
and
the
client
secret.
The
response
of
the
post
request
is
a
json
document,
including
the
id
token,
which
is
assigned
document
verifying
the
user
identity,
another
information
and
also
an
authex
token,
and
a
refresh
token.
A
A
Okay,
the
problem
with
the
code
flow
is
that
it
requires
a
server
bucket
application
which
can
store
safely
the
client
secret-
and
this
is
not
valid
for
some
single
page
applications
or
mobile
applications
which
run
the
client
and
the
secret
could
be
exposed
by
checking
the
code
they
compile,
etc.
For
these
cases,
there
exists
a
different
flow,
the
implicit
flow
which
is
used.
Let's
briefly
explain
it.
A
A
Okay,
again,
this
is
translated
into
a
get
request
to
the
authorized
endpoint
of
the
opening
provider
with
similar
parameters
as
the
previous
flow,
but
this
is
different.
The
response
type
is
token
id
space
id
token.
Instead
of
code
that
request
the
open
id
provider,
the
access
to
send
the
access
token
and
the
id
token
in
the
callback
to
the
application.
A
Again
in
this
step,
the
open
edit
provider
authenticates
the
user
with
any
mean,
and
once
the
user
is
correctly
authenticated
in
implicit
flow.
The
callback.
The
callback
now
includes
the
access
token
and
the
token
as
part
of
the
callback
url.
There
is
no
need
for
the
additional
exchange
step
that
was
in
the
code
run
flow.
So
now
the
application
has
the
id
token
to
verify
the
entity
and
could
use
the
access
token
to
request
additional
information.
A
A
However,
this
might
require
exposing
the
directory
to
the
internet
for
public
applications
and
if
you
are
using
credentials,
you're
not
using
credentials,
but
the
user
needs
to
re-authenticate
on
every
application.
So
we
don't
have
a
real
single
sign-on.
You
could
also
use
a
hardware-based
solutions
like
smart
cards,
but
you
need
to
support
that
in
the
application,
which
is
not
easy,
like
open
id
connect.
There
are
also
other
token-based
solutions
where
you
obtain
a
token,
which
is
the
proof
of
identity.
A
Security
asserted
on
markup,
language
or
xaml
is
another
protocol
which
serves
the
same
purpose
as
openid
connect.
It
is
older
based
on
soap
and
xml
documents,
and
it
is
mainly
designed
for
web
applications
with
a
back-end
server,
so
it's
not
well
suited
for
other
application
types.
But
apart
from
that,
it
is
still
a
valid
and
working
standard.
I
can
extend
more
into
the
differences
you
can
find
some
of
them
in
the
slide.
A
So
open
id
connect
should
not
be
confused
with
open
id
1
and
open
d2,
which
are
off
solid
and
predecessor.
Protocols.
Openid
started
back
in
2005
as
a
protocol
to
provide
identity
certificates
and
version.
2.0
was
widely
adopted,
but
it
is
now
deprecative.
Openid
connect
is
the
third
generation
and
it
dates
from
2014.
A
And
how
does
openid
connect
compare
to
oil
2?
Well,
openid
connect
is
built
on
top
of
ol2,
but
old
2
deals
with
authorization,
not
with
authentication.
What
is
the
difference?
For
example,
if
stack
overflow
wants
to
post
in
facebook,
the
user
authorizes
stack
overflow
using
oauth
stack
overflow
of
change
and
access
token
and
uses
that
access
token
to
post
using
the
facebook
api.
A
That
is
authorization,
but
if
a
stack
of
flow
only
allows
to
comment
if
your
reputation
is
above
above
50
points,
for
example,
then
authorization
in
this
case
is
done
in
the
stack
overflow,
but
the
stack
overflow
can
check
the
user
and
can
dedicate
the
authentication
to
a
provider.
For
example,
it
can
ask
google
to
identify
the
user
using
oauth2.
A
stack
overflow
obtains
the
access.
Token
uses
the
access
token
to
obtain
the
user
identity,
for
example
the
email
and
with
the
email
it
can
check
the
user
reputation
and
authorize
the
user
locally.
A
So
all
2
is
about
getting
keys
for
accessing
something.
Value
can
be
used
as
a
servo
authentication
mechanism,
in
the
sense
that
if
you
give
me
a
key
to
access
your
apartment,
probably
you
are
the
apartment
owner,
but
the
key
itself
doesn't
prove
your
identity,
so
in
open
id.
The
key
provides
access
to
a
document
certifying
your
identity
by
adding
the
id
token
and
a
user
info
and
point
to
o2.
So
some
people
call
this
abusing
the
standard
wall
to.
A
A
A
Some
strengths
of
openid
connect
are
shown
in
the
slide
like
it
is
interoperable,
secure,
easy
to
deploy
flexible
white
support
devices
and
so
on
so
which
protocols
should
you
use?
Probably
if
you
are
developing
a
mobile
application
or
writing
a
new
application,
you
should
use
oidc
in
which
cases,
for
example,
if
you
have
an
application
which
only
supports
ammo
and
the
identity
provider
supports
ammo,
then
probably
you
must
must
stick
with
someone
no
need
to
reinvent
the
wheel
in
here.
A
Okay,
now
I'll
show
you
some
useful
tools
to
help
you
debug
oitc
issues
on
how
it
works
they
are
listed
in
here,
and
we
will
see
a
couple
of
them
in
the
demo
and
also
the
browser
network
console
can
be
very
useful
to
check
what
is
happening
or
some
command
line
utilities
like
for
this
demo.
The
prerequisite
is,
you
need
an
open
id
connect
provider
where
you
have
a
client
register.
You
have
a
client
id
and
a
client
secret.
You
have
allowed
the
redirect
uris
in
the
provider
and
then
in
the
client.
A
A
A
And
when
I
click
login
I
can
see
there
is
a
callback
right.
The
penny,
the
provider
is
calling
the
callback
and
point
the
redirect
uri
providing
the
authentication
code
in
there.
So
the
next
step
we
are
using
the
authentication
code
flow
in
here
is
sent
a
post
request
from
the
backend
to
the
the
oidc
provider
to
exchange
that
code
with
the
id
token
and
the
access
token.
A
So
that
is
the
response
you
can
see
the
id
token
so
now
in
the
following
step,
you
can
take
that
id
token
and
you
can
copy
it
and
use
a
tool
yeah
like
jwt
load
io,
you
paste
the
token
here
and
you
can
see
the
code,
information,
the
signature
and
so
on
this
tool
already.
Does
that?
So,
if
you
just
click
verify
you
can
see,
the
token
is
valid
and
the
information
this
was
the
code
flow.
A
Now
we
will
check
the
implicit
flow
so
using
idc
divider
again
I
have
configured
the
openid
provider
in
the
credentials
in
there
and
now
what
I'm
going
to
do
is
in
the
response
type
and
removing
the
code
and
keeping
token
and
ad
token.
So
this
is
the
implicit
flow.
This
is
the
get
request
that
we
will
send
you
see
in
the
response
type.
We
have
token
blank
id
token
and
when
we
send
this
we
can
check
in
the
network
console
we
are
going
well
this
time,
as
I
was
already
logged
in
in
the
op
provider.
A
Okay,
this
was
the
demo.
Let
me
move
on
so
open
id
is
a
simple
protocol
open
id
connect,
so
it
can
be
implemented
from
scratch,
but
this
is
useful
is
not
necessary,
as
there
are
plenty
of
available
libraries,
some
of
them
certified
for
implementing
relying
party
clients
in
multiple
languages
or
to
implement
different,
open
id
connect,
servers
and
services.
Let's
see
a
python
example
using
the
flask
framework.
A
We
need
to
handle
the
callback,
the
callback
from
the
openid
provider
once
the
user
is
authenticated.
This
is
what
this
function
does
when
we
that
we
get
the
callback,
we
call
out
zero
dot
authorized
access
token,
which
will
automatically
exchange
the
receive
code
with
the
id
token
and
the
access
token.
This
library
already
handles
the
id
token
verification
and
the
coding
and
provides
an
easy
way
to
access
the
user
info.
A
So,
finally,
after
the
callback
we
redirect
the
user
to
the
dashboard
page,
we
create
a
login
page,
very
simple,
just
a
login
button
that
takes
you
to
the
slash
login
route,
which
starts
the
open
id
connect
dance
by
redirecting
the
user
to
the
open
id
provider.
You
can
see
the
view
and
the
controller
okay.
A
Finally,
our
dashboard
implementation
is
just
a
welcome
message
in
html
and
the
json
user
information
printed
in
row
and
the
dashboard
router,
the
dashboard
dashboard
controller
uses
the
requires
out
the
curator
to
make
sure
that
the
user
is
locked
in
or
otherwise
it
redirects
it
to
the
login
page
to
the
login
page.
So
this
was
a
simple
application
using
openld
connect
really
simple.
A
A
Previously,
most
of
our
tools
were
in
an
internal
data
center
using
ldap
authentication
against
the
internal
active
directory.
For
several
reasons,
we
started
moving
different
tools
for
devops
teams
to
the
cloud
jenkins,
hardboard
atlas
and
suite,
etc.
Exposing
the
active
directory
to
the
internet
wasn't
not
an
option.
So
there
was
an
our
interactive
directory
was
in
sync,
with
an
azure
active
directory
in
the
cloud
also
used
for
external
applications.
A
Azure
id
works
as
an
open
id
connect
provider
and
we
already
had
several
kubernetes
clusters
running
in
other
cloud
providers.
Also
using
open8d
connect
with
asu.
Also
one
of
our
requirement
was
that
all
the
applications
were
protected
by
an
application
gateway,
so
no
api
or
endpoint
is
exposed
to
the
internet
without
authentication.
A
Let's
start
with
the
easy
ones.
The
application
supporting
oidc
out
of
the
box,
so
kubernetes
has
an
auth
plugin.
You
set
it
in
the
cube
config
that
allows
you
to
trigger
oidc
directly
from
qfctl
by
opening
an
url
you
authenticate
in
azure
and
enter
a
code,
and
that
will
add
the
id
token
to
your
cubeconfig.
A
A
The
id
token
also
includes
active
directory
groups,
so
bindings
can
be
done
and,
for
example,
you
can
bind
namespace.
Permissions
per
rope.
Hardware
also
supports
oigc
out
of
the
box,
but
in
the
other
versions
in
the
time
of
implementation,
support
was
somehow
limited.
This
is
fixed
now,
for
example,
there
was
no
group
claim
support
now.
It's
configurable
a
hardware,
auto
onboards
users.
That
means
that
first
time,
a
user
logs
in
it
is
automatically
onboarded,
which
is
good,
but
the
onboarding
allows
the
users
to
set
its
username,
which
is
bad
because
that
is
not
homogeneous.
A
If
you
can
set
and
change
your
own
username,
also,
the
user
claim
was
hardcoded
and
the
username
claim
in
azure.
Active
directory
did
not
match
the
attribute
with
an
active
directory,
but
it
had
the
full
username
which
was
not
good.
So
why
work
on
a
pull
request
to
fix
the
latter
issues,
and
now,
with
the
latest
version,
you
can
skip
the
onboard
screen
and
customize.
A
The
username
play
also
jenkins
and
atlassian
suite
have
open
id
support
using
different
plugins
so
to
prevent
exposing
all
the
applications
to
the
internet
which
might
lead
to
security
breaches,
even
if
they
are,
if
they
require
internal
authentication.
Other
requests
were
processed
through
an
engine
source
balancer.
These
engines
would
force
open
a
d
connect
authentication
before
allowing
any
traffic
once
the
user
was
authenticated,
and
while
the
engine
session
cookie
was
still
valid,
requests
were
proxy
through
the
course
to
the
corresponding
application.
A
Please
notice
that
both
the
engines
and
balancer
and
the
internal
application
were
both
authenticating,
the
user,
but
as
the
user
was
already
locked
in
the
opening
connect
provider
assumed,
there
were
just
a
couple
of
redirects
in
the
browser
and
the
user
could
log
in
seamlessly
no
need
to
enter
the
password
or
the
credentials
again.
The
details
are
complex,
but
basically
engine
supports
oidc
in
the
plus
version
using
out
jwt
module
and
some
javascript
code
and
a
similar
implementation
exists
using
lua
for
the
open
source
version.
I
provide
the
links
in
the
slide.
A
There
was
an
additional
challenge
in
here.
What
happened
to
connections
that
were
not
http?
They
could
not
use
the
browser
cookies
to
verify
if
the
user
was
logged
in
for
these
connections
like,
for
example,
ssh
git
cloning,
the
user
ip
was
listed
on
successful
login
on
engines,
allowing
the
command
line
tools
or
similar
to
work
transparently
and
finally,
what
about
the
tools
that
did
not
support
openid
connect?
A
Fortunately,
just
a
few,
for
example,
the
sona
type
nexus
repository
well,
we
have
to
make
some
workarounds
nexus
didn't
support
ydc,
but
it
has
an
option
for
removing
remote
user
token
headers,
where
the
user,
identity
and
groups
can
be
provided
in
the
http
request.
Headers
as
sendings
is
proxy
not
request
to
nexus.
We
can
fill
those
headers
from
the
token
when
proxying
the
request
and
what
about
the
use
of
boarding?
The
user
must
exist
for
root
headers
to
work.
A
A
Other
caveats
that
we
found
is,
for
example,
the
user
migration.
It's
not
trivial
or
even
not
possible
to
migrate
the
user
from
the
all
attributes
in
the
active
directory
to
open
ap
connect,
not
just
a
matter
of
permissions
which
can
be
automated
or
scripted,
but,
for
example,
in
jira
and
confluence.
We
wanted
to
preserve
the
user
history
and
that
was
not
possible.
Also,
there
are
the
things
like
non-standard
iv
token
claims,
depending
on
the
provider,
some
providers
might
not
include
some
claims.
A
Like
the
email,
we
recently
had
an
issue
in
cystic
monitoring,
secure
integrating
with
an
oidc
provider,
because
the
email
was
missing.
Also
open,
abs
should
be
done
over
https
public
idc
providers
should
have
value
certificate,
but
if
you
are
building
your
infrastructure,
please
try
to
do
things
right
and
don't
use
the
sign
or
invalid
certificates.
A
A
So
you
need
to
do
some
tricks
to
propagate
the
logout
like
having
an
iframe
or
polling
or
whatever,
and
what
about
security?
Well,
it
should
be
safe
and
handling
credentials
more
easily
and
all
in
one
place
is
good
for
security,
but
remember
if
those
credentials
are
leaked,
multiple
tools
are
being
exposed
so
use
additional
measures
like
multi-factor
authentication.
A
A
So,
to
finish,
let's
recap:
the
good
open
ad
connect
is
modern,
easy
to
use
easy
to
implement
interoperable
flexible,
widely
supported
and
can
improve
security
and
make
your
users
happier
while
reducing
health
desk
incidents.
The
but
dedicating
credentials
management
to
a
single
service
can
raise
trust
and
availability
single
point
of
failure
issues
so
take
additional
measures
like
high
valuability
or
protect
the
credentials
with
multi-factor
authentication
and
the
ugly
well.
Some
implementation
and
standards
are
not
yet
perfect
and
some
applications
might
not
yet
support
openid
connect.
A
A
A
So
there
are
some
very
interesting
questions.
For
example,
a
mark
colert
pointed
out
in
in
the
questions
that
the
implicit
flow
is
deprecated
and
shouldn't
be
used
anymore.
That's
correct.
I
just
showed
a
couple
of
examples
of
typical
flows.
The
code
flow,
the
first
one
is
a
typical
one
for
web
applications
and
the
implicit
flow
is
one
which
could
be
used
for
non-web
applications,
for
example
mobile
applications.
But,
as
I
already
commented
on
some
slides,
it
has
some
caveats
some
security
issues.
So
there
is
an
alternative.
They
pick
a
pkc.
A
That
is
the
proof,
a
key
proof.
Key
code
exchange,
it's
a
different
flow
where
the
untrusted
application
can
generate
a
code
and
exchange
a
sent,
a
challenge
to
the
open
id
provider
and
then
verify
its
identity
without
having
to
to
keep
a
secret
like
the
code
flow.
Unfortunately,
I
am
not
100
sure
if
all
the
itc
providers
support
this
flow.
Probably
also
there
are
other
flaws,
as
some
other
people
commented
in
the
questions
like
the
client
flow.
A
That
is
intended
to
directly
authenticate
back-end
applications
with
open-aid
providers
without
interacting
with
the
users
and
also
there
is.
There
are
other
a
grant
types
like,
for
example,
supported
directly
by
oauth,
not
biopenet,
like
you
can
provide
the
directly
the
user
and
password
to
the
identity
provider
in
the
request,
in
the
request
that
is
sent
from
the
backend.
A
So
in
that
case,
for
example,
you
could
omit
or
don't
require
the
redirect
from
the
user
to
the
identity
provider
and
ask
the
password,
but
this
is
not
safe
as
you,
you
have
to
trust
the
application
to
keep
the
the
user
a
password
right.
The
point
of
open
id
is
to
delegate
the
authentication
completely
to
a
third
party
provider,
so
another
question
is
well.
Someone
noticed
that
his
provider,
his
provider,
is
not
sending
the
role
and
other
necessary
details
in
the
token
claims.
Well,
this
is
unfortunately
one
of
the
problems
I
found.
A
There
is
not
any
standard
of
what
are
the
claims
that
should
be
sent.
In
the
id
token,
some
providers
might
include
the
groups
or
the
roles
or
they're.
Not
and
probably
you
can
dig
into
your
provider
configuration
and
do
some
tuning
in
there
to
get
the
required
claims,
but
sometimes
it's
really
not
not
possible
at
all.
A
A
As
far
as
I
understand
you
trust
on
the
openid
provider,
and
if
what
you
want
to
check
is
that
the
behavior
of
your
client
application
is
correct,
then
you
can
try
a
mock,
open
id
provider
and
just
do
some
automatic
testing,
some
unit
testing
or
whatever,
to
verify
that
your
application
is
sending
the
request
correctly.
Handing
the
callback
and
receiving
the
id
token
and
doing
the
the
corresponding
verification,
and
so
also
another
question-
was
why
the
auth
token
and
the
id
token
are
different.
A
Okay,
so
really
wealth
is
about
authorization,
nothing,
not
authentication,
so
usually
using
the
wow.
They
forget
about
open
id.
What
you
get
is
a
pack
opaque
token,
a
which
just
is
just
a
key
that
you
handle
to
a
third-party
resource
server
to
access
some
api
or
whatever
the
difference
with
the
id
token
is
that
open
id
adds
an
extra
layer,
an
extension
over
out.
So
by
specifying
the
open
id
a
scope
parameter
in
the
in
the
out
step.
A
You
also
get
the
id
token
and
the
id
token
has
meaning
it
is
a
json
web
token,
where
you
can
find
the
user
information
and
a
signature.
So
you
can
verify
so
probably
the
id
token
can
be
used
as
the
auth
access
token.
I
mean
as
an
opel
or
opaque
token,
but
they
are
different
right
so
well,
let
me
check
how
to
use
oidc
with
a
trusted
party
in
such
a
way
that
it
will
not
require
so
many
redirects
for
application.
It
is
a
problem
with
user
experience,
as
there
are
three
redirects
right.
A
As
I
talked
before
the
point
is
you
are
delegating
authentication,
so
you
have
to
be
redirected
to
the
authentication
provider,
so
the
open
id
provider
authenticates
the
user
and
gets
back
to
you
you
could
use.
Probably
you
could
collect
the
username
and
password
or
from
your
application,
and
they
already
provided
to
the
openid
provider
using
the
the
password
run
type,
but
this
is
not
recommended
because
the
point
of
open
id
is
getting
rid
of
the
responsibility
of
of
having
to
collect
and
and
managing
the
user
and
passwords.
A
Okay,
let
me
check
some
new
questions
we
have
in
here
we
are
planning
to
use
azure
active
directory
and
on-prem
kubernetes
cluster
is
the
logout
supported
on
kubernetes
dashboard.
I
really
don't
know.
I
know
that
azure
id
has
has
a
logout
endpoint.
So
probably
you
could
do
something
on
your
kubernetes
dashboard.
A
So
when
you
log
out
on
the
kubernetes
dashboard,
it
just
already
directs
the
user
to
the
logout
endpoint
of
the
openid
provider
and
that
could
log
out
the
user
also,
but
a
logout
is
really
tricky
because
you
know
you
can
log
out
from
one
application.
You
can
log
out
from
the
open
id
provider.
So
in
case
the
the
user
is
redirected
to
the
provider.
A
A
So
in
order
to
have
a
global
logout,
you
will
need
to
coordinate
all
the
applications
first
to
log
out
from
the
provider
when
you
log
out
from
the
application,
and
then
you
could
need
some
kind
of
polling
or
notification
mechanism,
so
every
application
gets
a
notification
or
is
aware
that
the
user
locked
out
okay.
So
what
do
you
think
about
kick
cloak
for
implementing
oidc
er?
I
haven't
tested
it
thoughtfully,
but
from
what
I
know
it
works
correctly.
I
mean
it
implements
all
the
basic
flows
and
everything.
A
So
it's
a
good
ydc
provider,
so
how
useful
idc
for
matching
machine
to
machine
authentication
for
that
you
have
the
client
flow.
Probably
if
you
just
google
open
id
client
flow,
there
is
a
flow
I
just
showed
a
couple
of
them.
There
are
others
like
the
hybrid,
the
pixie,
the
pk
etc,
but
the
client
client
flow
allows
that
ready
to
the
backend
to
talk
to
the
provider
and
perform
the
the
user
authentication
and
okay.
A
A
Okay,
so
I
think
that's
all
all
the
questions
are
covered.
Let
me
check.
Oh,
there
is
a
second
page
in
here
sorry
image.
There
was
a
second
page,
but
I
don't
know
if
we
are
out
of
we
are
out
of
time
right.
So
maybe
we
can
follow
up
on
the
slack
channel.
Please
post
just
put
your
questions
in
here
and
I'll
be
glad
to
try
to
to
help
you.
Thank
you
very
much.