►
From YouTube: Secure and Govern APIs With Kong and Okta
Description
Learn how to implement powerful authentication and authorization scenarios with Kong and Okta. We will show you how to do sophisticated API access and API management flows with OIDC and OAuth – including how to plug Identity into your CI/CD pipelines.
Learn how Kong helps with security and governance: https://konghq.com/solutions/secure-and-govern-apis/
For more Kong demos and use cases, watch our Kong Summit 2021 videos: https://konghq.com/kong-summit/2021-videos
#Okta #APIsecurity #OIDC #OAuth
A
Today,
we're
going
to
take
a
look
at
decentralized
application
and
services
using
cone
connect
will
extend
our
use
case
by
implementing
authentication
and
authorization
scenarios
with
clonk
and
open
id
connect.
I
will
be
using
octa
as
my
oidc
provider.
I
will
show
you
how
you
can
do
api
access
and
api
management
flows
with
oigc
and
oauth.
Also,
I
will
touch
base
on
implementing
ci
cd
pipeline
with
dac
and
connect.
I'm
gonna
use
an
api
gateway
data
plane
deployed
in
vm
inside
the
docker
and
connected
to
my
instance.
A
Let's
quickly
hit
this
endpoint
with
insomnia
and
make
sure
that
endpoint
is
up
and
running
so
our
data
plane
is
ready
to
use
and
our
control
plane
is
ready
to
receive
commands
we're
gonna
using
deck
and
declarative
configuration
to
define
our
service.
In
this
example,
we're
gonna
use
http
bin
website
as
our
upstream
service,
and
we
will
configure
our
data
plane
using
following
path:
we're
going
to
use
name
as
http
bin
we're
using
path
as
http
bin.
A
Next,
we're
going
to
be
using
deck,
connect
sync
command
in
order
to
submit
these
changes
to
control
plane,
and
after
that
we
can
try
to
hit
this
url
and
point
and
see
a
result.
Http
endpoint
return
set
of
headers
return,
the
same
request
back
to
you
as
a
echo
service.
We
can
try
different
requests
in
this
particular
case.
We
will
get
a
200
request
response,
404
response,
503.
A
Next
we're
going
to
be
using
octa
to
configure
our
ydc
we're
going
to
take
a
look
on
two
examples.
Today,
one
example:
we're
gonna
be
using
integration
of
api
services
or
machine
to
machine
notification
in
another
use
case.
We're
gonna
be
using
oigc
with
a
single
sign-on
page.
Let's
start
with
this
client
credentials
and
machine
to
machine
communication,
we
will
configure
our
ydc
plugin
for
quank,
using
following
configs
client
id
and
client
secrets.
We
will
copy
from
octa
website.
A
Another
thing
to
configure
here
would
be
our
issuer
url
that
we
can
copy
from
security
api
place
from
octa.
Next,
let's
call
dec
connect
sync
again,
as
we
can
see.
Instance
of
open
id
connect.
Plugin
was
created
in
control
plane
and
these
changes
was
propagated
to
data
plane
because
the
next
time
when
we
hit
this
url,
we
start
seeing
new
response,
not
exactly
what
we
expected.
A
Let's
add
parameter
to
follow
this
request
and
what
we
will
see
we'll
see
the
page
that
says
bet
request
400,
and
this
happened
because
our
service
did
not
provide
or
our
client
did
not
provide
any
authorization,
header
information.
So,
let's
add
those
dash
a
parameter
allows
us
to
pass
authentication
headers
here.
So
in
this
example,
we
implemented
service
to
service
communication
using
open
id
connect
and,
let's
quickly,
take
a
look
into
this
authorization
header
that
includes
jot
token
we're
going
to
use
jot
debugger
at
token.dev
to
inspect
our
token
and
what
we
see
here.
A
We
see
our
issuer.
We
see
our
scope
that
was
configured
in
octa,
so
that's
something
that
we
can
take
a
look
and
the
application
use
to
investigate.
So
next
thing.
Let's
add
another
route
that
will
also
will
point
the
same
service
in
this
case
we're
going
to
configure
different
plugin
with
this
route.
We're
going
to
configure
another
use
case.
Now
this
route
was
created.
Let's
quickly
test
this.
A
We
also
call
same
status
endpoint
and
we
call
gettingpoint
now
in
this
case,
we'll
learn
how
we
can
use
octa
authorization
to
implement
a
login
screen
for
our
application
notice
here
that,
in
configuration
of
this
particular
use
case,
we
also
need
to
provide
a
redirect
url
in
order
to
after
successful
login
application.
User
will
land
on
particular
page.
So
let's
configure
this
odc
plugin
for
slash,
http,
bn2,
client,
id
and
client
secret.
We
copy
it
from
page
in
octa
and
issuer
here
also
specify
same
security,
api
issue
url
that
is
configured
in
our
account.
A
Next,
we
update
configuration,
we
invoked
deck
connect.
Sync,
I
would
like
to
open
incognito
window
that
doesn't
have
any
authorization
information
and
try
to
hit
this
url.
Now
I
see
octa
login
window.
Let's
take
a
look.
What
kind
of
users
are
allowed
to
log
in
here
and
we're
gonna
be
using
one
of
the
users
who
never
gonna
give
us
up
so
in
this
case
we're
gonna
use
login
as
a
rick,
astley
and
login
to
the
system
by
copying
and
investigating
this
job
token
using
jot
debugger.
We
can
take
a
look.
A
What
kind
of
information
we
also
can
get
from
this
token,
as
we
can
see
here,
some
extra
information
was
added
here
about
subject
and
about
group.
We
can
control
those
group
and
the
scopes
inside
the
octa,
and
after
that
we
can
propagate
this
to
our
application.
Our
application
can
read
this
token
inside
and
make
a
decision
what
to
do
with
this
user.
Last
but
not
least
now,
when
you
learn
how
we
can
do
declarative
configuration
of
your
control,
plane
and
data
plane,
you
can
embed
this
as
a
part
of
your
ci
cd
pipeline.
A
Let
me
show
you
quickly:
how
does
github
action
for
deck
look
like
as
an
example
so
for
action
that
happens
on
push
to
main
branch?
There
would
be
some
of
the
configuration
that
already
provided
by
people
from
kong.
You
will
have
setup
ready
to
use
in
deck
and
after
that
you
can
on
each
commit.
You
can
do
deck
connect
sync
and
we
will
providing
connect.
Email
connect
password
from
the
secrets
inside
github.