►
From YouTube: Lunch and Learn: OAuth
Description
2023-06-29 Lunch and Learn on OAuth at GitLab
Notes:
https://docs.google.com/document/d/13K3VT6j1OYnR_8qyLx10K8nLm3rkVFMF1E--EI-5wxc/edit?usp=sharing
A
A
A
That's
not
going
to
be
on
the
screen,
but
you
all
have
access
to
it
and
I'll
be
scrolling
through
it
and
kind
of
talking
through
it
here
and
also
like
this
is
really
casual,
feel
free
to
jump
in
if
you
want,
if
you
prefer
to
like
ask
a
question
at
the
end,
there's
a
questions,
there's
a
notes
section
at
the
end
with
nothing
in
it.
There
already
are
some
questions
under
the
section
frequent
support,
question,
frequent
support
issues
related
to
oauth,
so
maybe
I'll
just
add
a
little
header
under
them.
A
This
is
something
I
got
really
into
in
the
pandemic,
which
is
finding
pictures
of
my
dog
where
he
looks
like
Jake
Gyllenhaal.
It
has
nothing
to
do
with
oauth,
and
it's
purely
just
for
your
visual
entertainment,
so
I
just
this
is
this.
Is
it
this
is
visual
entertainment.
So
I
just
put
the
general
topics
on
each
of
these
slides
so
that
you're
something
to
look
at
and
then
I'm
going
to
talk
to
the
doc
so
oath
in
general,
as
Oreo
and
Jake's
faces
show.
A
This
is
quite
the
exciting,
potentially
scary
topic
I'm
not
going
to
talk
through
oauth
in
general,
partially
because
I'm
sure
many
of
you
already
know
a
lot
about
it
and
also
because
I
think
the
most
interesting
thing
to
talk
about
is
kind
of
like
what
does
oauth
look
like
at
get
lab
right,
because
many
of
us,
probably
all
of
us,
have
worked
at
different
software
companies.
Most
of
SAS
companies
support
oauth
in
some
way,
but
like
it's
a
little
different
everywhere
right.
So
the
question
is
like:
how
do
we
use
oauth?
A
How
do
we
talk
about
oauth
and
like
what
is
the
impact
and
on
our
customers?
So
with
that
being
said,
let's
get
into
the
first
one
get
lab
as
an
oauth
client.
So
this
honestly
like
when
I
think
about
oauth
at
gillab.
This
is
kind
of
the
primary
use
case.
That
comes
to
my
mind,
I
think
about
this
first
documentation,
page
that
I
linked
to
in
the
notes
where
it's
like,
hey
here,
is
a
giant
list
of
oauth
providers
that
we
support.
A
We
don't
support
all
these
on
gitlab.com.
We
support
a
small
subset
of
them,
but
self-managed
customers
can
enable
a
subset
of
these
on
their
instance
if
they
want.
Some
of
them
are
well
known,
like
obviously
GitHub
Facebook
atlassian.
These
are
Big
software
companies.
Some
of
them
are
a
little
more
obscure
and
we're
going
to
talk
about
that
a
little
bit
more
later,
but
we
definitely
support
many
I
think
over
20
oauth
methods.
So
it's
a
lot.
A
It's
a
lot
to
learn
about
I'm
sure
our
friends
and
support
have
gotten
some
obscure
questions
and
you're
like
wow.
What
even
is
this
and
that's
you
know?
Choices
were
made
in
the
past
to
support
these
and
we're
working
on
deprecating,
some
of
them,
but
that's
always
a
big
challenge,
and
then
the
second
bullet
I
have
here
is
that
you
know
oidc
and
Samuel
are
themselves
oau
strategies
and
they
could
be
some
topics
that
we
went
into
during
this
presentation.
A
So
one
thing
that's
interesting
and,
like
so
I
know
how
we
use
oauth
right,
like
I,
am
familiar
with
these
methods
and
as
I
was
going
through.
Creating
this
presentation
I
was
like
oh
this
is.
It
is
kind
of
strange
that
we
you
we
like
gitlab
is
the
oauth
client
in
these
scenarios,
but
we're
really
using
it
in
a
single
sign-on
capacity
right.
B
A
Don't
do
that
we're
just
using
it
as
a
single
sign-on
method,
which
is
different
than
how
oauth
is
used
in
some
cases
right.
So
in
some
cases,
oauth,
like
the
whole
point
of
the
a
lot
of
flow,
is
to
get
an
oauth
access.
Token
use
that
access
token
to
make
a
request
to
the
resource
server.
In
this
case
gitlab
or
in
this
case
sorry,
the
external
service,
which
would
be
Twitter
Facebook
atlassian
OCTA.
But
we
don't
do
that,
we're
just
using
it
to
say.
Okay,
you
know
sign
in
to
gitlab.
A
You
don't
need
a
password,
just
use
your
credentials
from
this
other
service
and
then
come
back
here
and
you'll
be
logged
in
and
of
course,
users
can
set
up
as
many
oauth
methods
as
they
want
in
gitlab,
which
I
assume
is
a
benefit
to
them.
They,
like
the
idea
of
I,
can
set
up.
You
know,
Gmail
I
can
use
my
Gmail
to
log
in
or
I
can
use
the
password
or
I
can
use
different
methods.
I
think
that's
pretty
flexible
for
users
I'm
sure
it
also
leads
to
a
lot
of
confusion.
A
Oh
yeah
good
idea
back
and
we
can
move
some
of
this
content
to
the
docs
too
great,
so
we're
walking
through
this
so
anyways.
That
was
one
thing
that
kind
of
I
don't
know.
If
anybody
else
has
this
experience,
but
one
thing
that
confused
me
when
I
started
working
at
gitlab
is
that
people
describe
oauth
as
single
sign-on,
which
I
like
had
not
thought
of.
Oauth
has
sign
and
then
seamlessly
on
the
past,
because
I
wasn't
using
it
in
that
capacity.
A
I
was
using
it
as
a
way
to
get
access
to
another
service
right,
you
authorize
with
a
service.
We
can
auth
access
token,
and
then
you
can
access
resources,
but
it
wasn't
like
the
single
sign-on
method
you
weren't
signing
into
this
external
service.
So
that's
one
way
that
I
would
say
that
a
lot
that's
a
little
bit,
maybe
different,
like
a
lab
and
the
way
we
talk
about
it
than
in
some
other
places
that
I've
worked
so
moving
on.
A
Each
of
connection
isn't
saved
as
an
identity
associated
with
the
user
record
and
I've
linked
there
to
the
identity
class,
and
then
users
can
then
go
in
and
manage
their
connected
accounts
in
their
profile
and
then
the
final
one
is
the
real
mind
Bender,
which
is
that
you
can
also
have
git
lab
as
and
gitlab
can
be
both
the
oauth
client
and
the
authorization
resource
server.
So
if
somebody
has
self-managed
gitlab,
you
can
log
in
to
self-managed
gitlab
with
getlab.com.
B
A
A
So
then
that's
the
first
use
case.
So
in
that
case,
get
lab
is
the
oauth
client.
It
is
receiving
information
from
another
service
that
is
saying,
okay,
login
with
user.
Also,
the
the
opposite
is
gitlab
can
be
the
authorization
or
resource
server,
and
this
is
actually
I
didn't
know
until
just
researching
this
that
and
an
oauth
app
a
gitlab
oauth
application
can
be
at
the
user
level.
A
I
knew
that,
but
it
could
also
be
at
the
group
level
or
an
instance-wide
application
and
I
thought
there
was
a
question
below
of
a
frequent
support
question
of
like.
Why
would
you
use
one
of
these
over
the
other?
Does
anybody
have
a
good
answer
to
that
question
like?
Why
would
somebody
choose
I
can
imagine
that
you
wouldn't,
for
example,
in
an
organization,
want
one
individual
person
to
create
an
oauth
app
that,
like
that
they
own
in
case
what,
if
they
left
the
company
and
then
that
belongs
to
their
account?
B
D
D
D
B
I
am
not
sure,
so
if
you
are
talking
about
over
tab,
so
probably
if
you're
creating
an
oath
app
at
a
group
level,
then
the
group
owner
can.
That
means
the
group
owner
has
an
has
ability
or
the
access
to
add
all
add,
to
assign
the
application
to
all
the
users
within
that
group
and
for
the
instance
wide
application.
The
same
kind
of
ability
goes
to
the
instance
owner,
but
for
for
an
user
owned
application
it
would
be
mostly
for
developer
development
purposes
or
testing
purposes.
A
That's
a
good
thing
for
us
to
follow
up
on
because,
like
that
idea
of
the
member
the
membership
affecting
it
I'm,
not
positive
that
if
it's
at
the
group,
if
the
oath
app
is
at
the
group
level,
but
the
membership,
it's
only
scoped
to
members
of
that
group,
it
could
be
the
case,
but
I'm
not
positive.
So
this
is
a
great
question.
We
can
come
back
to
it.
E
Oh,
that
was
me
that
was
me.
I
turned
my
camera
off
because
it's
night
yeah
so
I
think
the.
So.
The
question
is
about
using
gitlab
as
the
identity
provider
right.
Yes,
so
I'm
thinking
that
the
user
on
the
application
is
what
kind
of
what
smriti
was
talking
about
in
terms
of
the
user
will
configure
it
for
their
own
or
whatever
application
there,
because
it
redirects
right.
So
you
use
gitlab
as
the
identity
provider
you
sign
into
git
lab
and
it
redirects
to
some
other
place
right.
E
A
Think
the
good
the
good
thing
about
this
question
or
why
I
like
this
question,
is
that,
like
if
a
group
of
people
who
are
working
on
on
you
know,
identity,
accitlab,
don't
know
why
you
would
use
these
like?
Maybe
that
means
there's
room
for
improvement
documentation.
Maybe
it
means
one
of
these
features
like
doesn't
really
make
sense
like.
Why
do
we?
Why
do
we
allow
group
and
personal,
like
maybe
personal,
shouldn't,
exist
or
I?
B
A
The
way
I'm
I
noticed
that
you
use
the
term
identity
provider.
That's
also
the
term
that
I
always
think
of
because
I
think
about
saml
and
in
saml,
like
the
service
that
is
providing
the
credentials
for
the
user.
That
is
saying
like
this
is
who
this
user
is?
Is
the
identity
provider
in
the
oauth2
spec?
A
They
call
that
the
authorization
server
and
then
there's
further
like
a
resource
server
which
sometimes
they're
separate
in
the
case
of
gitlab.
They
are
the
same
thing,
so
the
gitlab
monorepa
monorail
is
both
the
authorization
server
and
the
resource
server
in
the
context
of
oauth.
So
it's
a
new
learning
for
me,
so
anyways,
the
gitlab
is
authorization
and
resource
server.
Behavior
is
defined
by
door
keeper.
Somebody
put
in
these
notes
before,
like
what
are
the
gotchas?
A
In
the
context
of
git
lab
providing
the
oauth
identity,
we
have
a
config
file,
I
linked
to
it
in
there.
Well,
this
is
a
relatively
new
change.
Thanks
to
some
people
on
this
call,
I
think
imra.
You
worked
on
ashing
or
no.
It
was
true
worked
on
hashing.
It
was
Drew
and
Abu.
Bakr
I
worked
on
hashing
oauth
access
tokens
and
oauth
application.
A
Secrets
I
know
that
caused
a
few
challenges
for
users,
because,
as
a
result,
we
can
only
show
your
oauth
application
secret
right
after
it's
created
and
after
that
we
hash
and
throw
in
the
database,
and
we
can't
get
it
for
you
anymore.
So
that's
I,
I,
don't
know
if
people
in
support
have
had
issues
with
that
I
know
when
it
first
happened.
There
were
some
ux
questions
around
this,
but
it
is,
you
know
better
than
storing
anything
contests.
So
that's
it.
C
A
C
A
A
It's
a
good
transition,
but
the
hard
ux
another
little
just
tidbit
here
is
that
we
do
trust.
We
support
trusted.
Client,
apps
I
am
guessing
that
the
vs
code,
one
do
you
know
imra
of
the
vs
code.
Instance-Wide
client
application
is
trusted,
meaning
when
you
connect
with
it.
There's
no
screen
that
says
like
do
you
authorize
gitlab
to
access
your
identity
with
this
scope,
it
just
like
said
just
kind
of
sends
you
and
then
sends
you
right
back,
because
it's
marked
as
trusted.
A
That's
fine,
I
I
think
this
came
up
actually
one
of
the
conversations
with
the
team,
the
code
suggestions
team
because
they
were
doing
some
kind
of
an
oauth
or
they
were
discussing
doing
an
oauth
and
oidc
flow
and
they
were
wondering
how
to
make
it
more
seamless
and
one
way
to
do
that
is
to
have
a
trusted
oauth
app,
because
then
you
don't
have
that
whole.
You
know,
click
accept
rule.
A
We
don't
have
this
documented
anywhere,
it's
just
door
keeper,
behavior
that
we
do
support
and
I
assume
we
support
it
for
an
internal
use
case,
that's
pretty
common
great
and
so
then
expiring,
oauth
access
tokens.
This
is
a
relatively
new
change
that
we
had
was
a
breaking
change
in
15.0
that
we
don't
support.
Non-Expiring
access
tokens
before
that
we
would
say:
hey
we'll,
give
you
an
access
token.
You
can
use
it
as
long
as
you
want.
If
that's
what
your
setting
is
now
they
have
to
expire
within
two
hours.
A
This
was
another
place
where
doorkeeper
caused
us
some
issues
related
to
the
refresh
flow.
We
thought
that
we'd
added
expiration
to
all
of
our
tokens,
but
there
were
still
some
left
over
that
didn't
have
a
expiration,
and
this
was
another
I
put
this
below.
This
was
a
gotcha
to
me.
I
also
expected
that
somewhere
in
our
database,
there
would
be
a
table
called
refresh
oauth
refresh
tokens
I'm
like
where
are
the
refresh
tokens.
Where
are
the
refresh
tokens?
The
refresh
token
is
saved
on
the
oauth
access
token.
A
A
B
C
A
Already
done
so,
somebody
had
done
that
long
before
I
worked
at
git
lab,
but
we
still
had
customers
I,
believe,
like
government
customers,
people
who
have
high
compliance
needs
who
are
like.
Well,
you
you
say:
you've
mitigated
it,
but
like
we're
getting
these
flags
in
the
compliance
reports
that
you're
not
on
the
on
the
off
like
you're,
not
an
omnias
2.0,
the
gem
version
that
like
prevents
that
for
everybody.
So
that
was
an
interesting
Journey.
A
C
A
You
can
see
which
ones
it
is
it's
Omni
off,
Salesforce,
omniac,
Azure,
omnias
crowd,
Omnia
lab
is
vendored
for
a
different
reason,
but
we
and
we
there
were
more
before
but
we've
upstreamed.
Our
changes,
which
has
been
really
great,
like
I,
think
this
has
been
a
really
good
venue
or
Avenue
for
people
on
off
to
participate
in
the
open
source
Community,
because
we're
using
these
gems
and
a
lot
of
them
really
need
some
more
love
and
attention
than
they're
getting
now.
A
So
in
some
cases
we've
been
able
to
make
to
submit
patches
that
have
been
accepted,
which
has
been
great
but
not
in
all
cases.
So
that's
something
to
note
and
also
just
like
a
wild
experience
going
through
all
of
our
gems.
You
can
type
up
that
a
little
more
later
in
terms
of
our
Ruby
upgrades
as
well
and
then
deprecating
and
moving
oauth
options.
A
This
one
is
challenging,
so
we
have
an
okr
around
consolidating
and
replacing
unmaintained
gems
and
a
lot
of
the
gems
that
fit
under
the
auth
bucket
are
these
omniac
gems.
So
we
and
I
think
like
this
was
a
little
bit,
maybe
my
fault
of
when
I
started
at
gitlab
and
I
saw
this
I
was
like.
Oh,
we
should
deprecate
like
this
is
really
old.
We
should
deprecate
it,
and
then
we
made
those
announcements
and
then,
of
course
nobody
notices.
Nobody
reads
the
docs,
nobody
notices,
you're
gonna
deprecate,
something
until
you
have
actually
removed
it.
A
A
I,
don't
know
what
year
that
was
a
long
time
ago,
and
then
we
removed
it.
We
forgot
to
remove
it,
but
we
removed
in
59,
and
then
it
was
reintroduced
by
the
community
in
16-1
which
honestly
like
good
for
them,
because
if
they
did
everything
we
asked
them
to
do
we
didn't
make
it
easy.
We
didn't
say:
oh
just
submit,
you
know
one
liner,
they
had
to
Fork
the
jam
re-release
it
make
some
updates,
so
they
did
that
and
so
we're
back.
We
have
shibboleth
again.
A
We
have
it
with
us
as
we
removed.
We
haven't
reintroduced
it,
but
there
are
a
lot
of
people
in
that
issue
who
are
unhappy.
Some
of
them
are
existing
customers.
Some
of
them
are
prospective
customers.
So
that's
challenging
the
morale
perspective
for
me,
but
you
know
it
is
I.
Think
Otto
was
the
one
who
said
that
was
it
IBM
who.
B
F
A
A
and
it's
hard
because
in
these
cases
these
are
like
enterprisey
authentication
methods
that
it
might
be
difficult
for
these
companies
to
remove
like
it's,
not
just
them
complaining
like.
Oh,
this
is
Annoying
It's,
Like,
This,
Is,
How
They
log
into
things,
and
they
don't
they're
not
going
to
have
the
budget
to
move
something
cool
and
fancy
like
OCTA
this
year.
A
A
Great
and
then
the
final
section
that
I
want
to
talk
about
was
shared
oauth
setups,
and
this
came
up.
This
week's
really
came
to
back-end
pairing,
which
is
really
fun,
and
she
was
queuing
in
a
community
Mr
where
somebody
had
added
a
new
group
claim
in
for
oidc,
and
so
we
spent
it
was
the
two
of
us
and
then
like
two
other
people
spent
two
hours
setting
up
oidc
locally
on
our
machine
and
one
person
in
that
call.
A
Well,
all
of
us
had
probably
done
it
at
least
once
before,
and
one
person
had
done
it
like
pretty
recently
and
was
like
yeah.
It
took
me
forever
and
so
I
guess
this
is
like
one
like
well,
so
one
reason
it
would
be
great
to
do.
This
is
just
for
situations
like
smyrdie
was
in
you
know:
I
got
an
MR.
This
person
added
something
to
an
existing
oauth
strategy
like
let's
try
it
out.
A
A
So
it
was
difficult
to
know
without
just
setting
them
up,
and
so
that
was
pretty
time
consuming
and
it
would
be
awesome.
It
would
be
easier,
so
I
would
love
to
collaborate
with
everybody
on
sharing.
Just
like
you
know,
config
file,
setups
really,
but
then
also
maybe
some
instructions
on
how
to
set
up
a
new
Olaf
app.
A
This
would
obviously
help
our
customers
as
well.
If
we
improve
our
documentation
on
how
to
set
things
up
and
anyways,
that's
just
something
that
I've
been
thinking
about
recently.
So
with
that
I
think
just
gonna
do
some
q
a
here,
so
we
have
some
first
of
all,
does
anyone
want
to
add
new
questions,
or
does
anyone
have
any
topics
that
we
didn't
talk
about
today,
because
this
is
very
like
high
level
Olathe
kit
lab?
We
can
get
into
some
nitty-gritty
if
you
want.
G
G
This
is
very
technical,
so
I'm
just
going
to
ask
a
high
level
question
and
please
let
me
know
if
that
should
be
maybe
more
one-on-one
conversation
or
something
that
should
not
be
discussed
in
that
call,
but
I'm
I'm
just
interested
generally
about
the
the
position
of
oauth
generally,
because
we
had
a
few
very
confusing
case
with
sales
and
just
discovered
that
sales
is
generally
not
super
aware
or
in
in
control
of
those
feature
when
it
comes
to
clients.
So
I
was
just
wondering:
where
is
this
going?
G
You
know
like
in
the
in
the
future
in
terms
of
penetration
with
the
with
the
customers
you
know
like?
Is
it
going
to
develop?
You
know
like
once
the
the
ratio
of
usage
anything
like
this
and
I
have
a
couple
of
other
questions,
but
just
as
a
as
broadly
as
it
gets
for
now,
you
know
is
in
anything
you
can
share
on
that.
A
G
Yeah
pretty
much
because
we
I
got
like
the
past
year.
I
got
three
times
where
we
had
to
do
legal
languages
for
accommodating
that
feature
for
some
of
the
customers
and
for
us
in
terms
of
contract.
It
just
boils
down
as
creating
a
license
key,
limiting
the
features
on
this
single
one,
and
that
creates
a
lot
of
complication,
because
you
need
to
create
Audits
and
stuff
like
that,
I'm
not
going
to
get
into
the
details
of
the
legal
language.
But
it's
it's.
G
It's
very
sort
of
complex
from
contract
management
perspective,
so
I
was
just
wondering
since
I
know,
before
those
cases,
I
knew
nothing
about
that.
You
know
and
I'm
hearing
hearing
the
content
of
that
meeting
was
very
helpful,
but
I
was
just
wondering
for
somebody
who's,
not
part
of
that
team
and
where
we
have
to
you
know
give
that
feature
to
some
customers.
You
know
like.
Where
is
this?
Is
this
going
to
to
develop?
You
know
like:
what's
the
current,
you
know
usage
of
that
feature
amongst
our
clients.
A
I
would
say,
and
others
can
jump
into
because
I
know
we
got.
You
know
Otto
here,
who's
the
manager
of
the
auth
team
and
has
the
full
perspective
and
other
folks
who've
been
at
gitlab
a
long
time
from
what
I
can
tell
based
on
like
the
focus
of
our
team
and
the
features
that
I
see
getting
attention.
Stanl
oauth
is
a
huge
Focus,
because
saml
is
what
Enterprises
want
to
use
to
have
more
control
over
the
access
that
their
employees
have,
and
they
want
to
be
able
to.
A
When
that
employee
leaves
the
company
remove
their
access
from
everything
easily
right
with
SSO,
and
so
they
remove
their
access
over
in
their
single
sign-on,
and
then
they
can't
log
into
galab
anymore.
Their
access
is
shut
off,
which
is
what
I
mean
that's
what
we
do
right
at
gitlab
with
OCTA.
We
have
OCTA
to
access
lots
of
things
so
that
when
people
leave
the
company
you
can
easily
make
sure
that
we're
in
compliance
their
access
is
removed.
So
I
I
would
say.
A
F
Yeah,
just
just
to
back
up
back
up
on
that
generally
is
a
strategy
is
probably
one
of
the
core
areas
that
we
will
have
for
the
foreseeable
future.
So
when,
when
folks
ask
someone
say,
hey
ldaps
Etc
and
these
three
are
probably
all
equally
large,
but
then,
but
the
newer
types
are
the
ones
that
are
adopted
more
and
more
will
be
saml
or
a
lot
or
specifically,
when
people
care
a
bit
less
about
authorization
and
a
bit
more
about
authentication.
It's
also
a
bit
more
lightweight
in
terms
of
adoption.
F
So
if
you
look
at
our
usage,
I
think
Google
auth
has
a
lot
has
pretty
large
usage,
so
I
don't
expect
it
to
go
away.
I
think
it
will
stick
around.
We
haven't
had
a
lot
of
asks
from
an
enterprising
terms
like
adding
more
features
to
it.
So
that's
why
you
might
not
see
it
in
terms
of
our
roadmap,
but
it
will
be
around.
G
G
That's
helpful
because
when
you
know
the
again,
it's
really
just
to
try
to
be
consistent.
You
know
with
what
the
customer
expects
and
what
we
can
deliver
from
contract
perspective.
The
the
case
I
was
talking
about.
It
was
with
a
Gameloft
Nea,
of
course,
used
for
connection
with
matter
most,
which
is
the
the
internal
sort
of
equivalent
of
Slack.
G
So
you're
probably
know
that
use
case
as
well,
and
that,
when
you
know
through
numerous
people
and
numerous
sort
of
like
calls
to
understand
exactly
what
that
was
supposed
to
mean,
including
whether
those
users
should
be
built
or
not,
and
there's
quite
of
a
set
of
open
topics
as
well.
You
know
with
with
that
regard
so
I'm.
What
I'm
trying
to
do
here
is
just
trying
to
understand
whether
this
is
going
to
be
a
growing
demand.
You
know
and
Android
to
identify.
G
C
G
G
B
F
C
A
D
A
E
This
is
another
one
that
I
can't
I
can't
find
it
right
now.
I
can't
find
it
right
now,
but
there's
another
one
that
you
could
use.
So
the
OS
debugger
is
like
it's
useful.
If
you
want
to
see
what
so,
for
example,
if
you've
configured
gitlab
as
the
identity
provide,
as
the
you
know,
identity
provider,
you
can
use
the
oauth
debugger
to
see
what
it's
sending
and
you
can
do
the
same
if
you've
configured
some
other,
like
you
know,
Azure
or
something
like
that.
E
You
can
point
it
to
this
thing
and
it'll
show
you
what's
being
written
and
it
it's
able
to
decrypt
it
as
well.
It's
able
to
decrypt
the
response
quite
nicely
as
well.
So
it's
it's
quite
nice,
but
this
tool
is
used
mostly
for
seeing
what
the
authentication
the
authorization
server
is
returning
right.
There
is
another
tool
that
I
used
to
mess
around
with
quite
a
bit.
There
was
actually
a
pre-configured
or
auth
provider.
E
Some
some
of
our
customers
actually
use
key
clock,
but
no,
it
wasn't
key
clock.
It's
like
this.
It's
this
pre-made
identity,
it's
this
pre-made,
oauth
identity
provider,
and
so
they
give
you
the
the
URL
and
the
metadata
URL,
and
everything-
and
all
you
have
to
do-
is
just
put
that
stuff
in
and
you
can
then
try
and
you
can
use
it
all.
The
user
database
is
open.
E
A
E
I
I
asked
that
question
from
a
non-dev
background.
I'm
I
don't
come
from
a
background,
so
the
question
was
more
from
a
non-dev
breaker
I
like
yeah.
How
so
I
know
like
you've
explained
earlier
in
the
in
the
call
that
you
know
we
use
the
door
keeper
gym
to
when
we're
using
gitlab
is
an
authorization
server,
but
do
the
different
oauth
providers
use
different
gems
like
I
I,
see
that
there's
like
a
an
omni
off
controller.
A
It
is
one
omniath
provider,
one
on
Yahoo
client
that
you
can
set
up,
and
so
people
can
log
in
with
saml
and
they
so
they
they
click
on
the
sign
in
with
saml
button
on
galab
they're
sent
over
to
some
other
place
that
make
they
log
into
and
then
send
information
back
to
us,
and
so
the
way
you
set
it
up
from
like
an
admin
perspective
is,
is
very
similar
to
any
other.
Like
oauth
strategy.
A
Right,
like
you,
have
to
add
some
configuration,
some
information
about
your
your
saml
app,
but
it
is
a
different
protocol,
so
it
uses.
If
you
look
at
the
docs
there,
it
has
like
the
ID
piece
or
fingerprint
the
idps
so
Target
URL.
So
it's
it's
a
little
bit
different
from
kind
of
the
more
generic
oauth
apps.
A
Okay,
I'll
revisit
it,
I'll
I'll
look
up
some
metaphors
or
something
do
some
thinking
on
that.
Edward
Eduardo
asked
a
question
here
about.
Why
do
you
want
to
remove
Facebook
oauth
love
this
question?
So
there
is
a
little
bit
of
discussion
in
the
related
issue.
If
you
click
on
that
and
part
of
it,
is
that
there's
very
little
usage,
so
we
do
have
graphs
that
show
us
the
overall
usage
and
it's
very,
very,
very
tiny,
the
camera,
what
it
is,
but
it's
like
doesn't
even
show
up
on
our
usage
graph.
A
It's
so
small
and
then
the
gem
is
somewhat
maintained,
but
we
are
like
five
major
versions
behind
so
I
would
assume
I
haven't
actually
looked
that
deeply
into
this,
like
I
would
assume
that
the
version
that
we
are
on
in
the
Omnia
Facebook
gym
right
now,
like
it's
just
entirely
different.
We
got
to
do
a
whole
complex
kind
of
upgrade
process
like
oh
now,
you
know,
you're
gonna
have
to
use
these
different
configurations
right.
I
think
I
think
the
version
we're
using
is
almost
10
years
old.
A
It's
a
really
old
gem,
so
we
would
have
to
provide
a
path
for
customers
to
upgrade,
which
is
quite
a
lot
of
effort
right
like
that.
That
itself
is
a
breaking
chain
to
say
we're
going
to
upgrade
the
Facebook
Gem
and
now,
when
you
configure
Facebook
as
an
oauth
provider,
you're
gonna
have
to
do
this
that
and
the
other
it
might
even
be
that
the
this
happened
with
Twitter
as
well,
that
our
Twitter
gem
only
supports
like
oauth
1.0
and
there's
the
New
River
like
if
we
wanted
to
support
the
newer
oauth
protocol.
A
This
is
the
gem
version,
but
the
newer
OS
protocol
we
would
have
to
use
a
totally
different
Library
have
different
configurations.
I
mean
that's
a
lot
of
effort
to
go
through
for
something
that
almost
nobody
is
using.
So
it
seems
like
the
easier
approach
is
just
to
to
deprecate
it
and
then
the
other
thing
is:
it's
also
not
very
disruptive
to
customers
to
do
that,
because
they
can
just
set
up
a
password
on
their
account
like
it
doesn't
lock
them
out
of
their
account
forever.
H
A
No
problem,
we
do
also
have
a
lab
dependency
quality
guideline.
That's
relatively
new
that
I
would
say
almost
none
of
the
gem
that
last
gems
really
neat.
Definitely
the
Twitter
one
doesn't
in
terms
of
it,
doesn't
have
the
test
coverage,
it
doesn't
have
CI,
it
just
doesn't
meet
our
standards.
So
it's
like.
We
either
find
a
new
gem.
It
doesn't
exist.
We
build
it
ourselves
so
that
that
is
another
reason
in
terms
of
that.
A
H
Maybe
there
is
a
learning
thin
opportunity
here
right
that
embracing
things
that
are
of
low
quality
or
it
has
a
price
right
and
I-
think
we
are
paying
the
price
ourselves.
So
maybe
we
need
to
be
more
careful
about
a
what
James
are
we
using
in
the
future,
because
otherwise
we
are,
we
can
be
in
a
corner
ourselves
in
in
a
very
bad
situation.
A
Yes,
yes,
and
that's
like
the
omniac
upgrade
and
then
every
Ruby
upgrade
we've
had
to
again
manually
test
a
lot
of
these,
so
it
is
an
ongoing
burden
on
us
to
maintain
them.
It's
not
just
like.
Oh
it's
just
set
it
and
forget
it.
It's
over
there
working
and
in
fact
footer
oauth
does
not
work
on
gitlab.com
right
now
and
we've
gotten
one
issue
about
it.
I
think
it's
been
broken
for
months,
so
it's
not
even
working.
Currently,
we
might
be
able
to
fix
it
we'll
see.
A
A
A
So
that's
why
I
kind
of
noticed
it,
but
it's
not
documented
everywhere.
It's
not
part
of
the
public
API,
but
we
do
support
it.
We've
been
I,
looked
in
the
git
history
even
to
see
when
we
started
supporting
it.
It's
been
in
there
since
the
code
was
ported
over
from
somewhere
else
like
there's,
you
can't
even
Trace
when
we
added
it.
So
there's
not
a
lot
to
know,
but
we
do
support
trusted.
Oauth,
apps.
A
A
There
was
a
really
great
example
of
this
recently,
which
is
that
we
so
with
oidc,
and
this
is
where
I
get
confused
in
terms
of
describing
it
a
whole
high
level
difference
between
oidc
and
oauth,
but
like
when
you
use
the
open,
ID
connect
strategy
to
log
in
with
kitlab.
It's
like
a
regular
oauth
flow.
It
logs
you
in,
but
then
it
sends
you
an
additional
Json
web
token.
A
That
includes
information
about
the
user
and
I
know.
Abu
Bakr
has
been
pushing
us
to
use
to
lean
on
oidc
in
more
use
cases
and
I.
Think
part
of
the
benefit
is
that
if
you
need
additional
information
about
the
user
account,
you
could
just
get
it
from
that
JWT.
You
don't
even
have
to
make
another
request
to
get
lab
using
the
auth
access
token.
You
just
have
that
information
already
and
you
can
add
different
information
into
that.
Jwt,
that's
helpful!
So
that's
really
nice.
A
An
oidc
is
supported
by
a
lot,
so
we
set
up
the
screen
now
when
you're,
repairing
oidc
is
supported
by
OCTA.
That's
what
we're
using
right.
We
set
up
OCTA,
yes,
yes,
yes,
so
we
set
up
OCTA
using
the
open,
ID
connect
oauth
strategy,
and
then
you,
the
user
Logs
with
OCTA.
Then
we
log
them
in
on
our
side.
We
get
the
response
back,
we
say
great,
you
are
this
user.
This
is
your
email
address
boom
you're
in
and
then
we
also
have
this
JWT.
A
That
contains
information
in
the
case
that
she
was
testing
the
that
Json
web
token
with
oidc
contained
information
about
which
groups
in
that
oauth
resource
server
and
OCTA
are
auditor
groups.
So
it's
like
make
anybody
who's
in
that
group.
An
auditor
in
gitlab,
which
is
pretty
cool,
so
I,
feel
like
there's
a
lot
of
extensions.
You
can
build
onto
that
where
you
can
add
different
things
into
oidc
different
claims
and
then
do
interesting
stuff
in
terms
of
assigning
users
to
groups
and
knowing
what
their
access
levels
should
be,
and
things
like
that.
F
Yeah,
why
do
you
see
usually
comes
up
as
like
a
very
lightweight
protocol?
So
if
anytime
I
have
to
write
like
my
personal
app
I'm
like
yeah,
why
do
you
say
simple
enough?
Throw
the
claims
in
in
user
object
and
a
token
and
I'm
a
happy
camper?
Of
course,
the
Samo
requires
a
bit
more
parsing
to
understand
how
that
assertion
is
going
to
work.
B
A
F
A
F
A
A
I
found
my
way
into
developer.twitter.com
and
I
posted
about
the
captcha
they
made
me
do
it
was
the
most
intense
capture
I've
ever
had
to
do.
I
it
was
it
was.
It
was
again
IQ
test
that
I,
failed
and
so
I
got
him.
I
got
into
developer,
console
I
created
a
new
oauth
app
and
I
was
able
to
with
my
GDK
login
to
Twitter
I
log
into
gitlab
with
Twitter,
so
our
existing
Library
does
somehow
work,
but
the
one
that's
on
the
setup
on
gitlab.com
doesn't
work.
A
A
Yeah,
it
is
I
guess,
as
you
know,
the
bots
gets
smarter.
The
captions
get
harder,
so
anyways
Twitter
the
Twitter
saga
continues,
but
we're
near
the
end
of
our
time.
We're
actually
passed.
I
said
it's
gonna,
be
a
50
minute
meeting
and
we're
now
past
that.
So
thank
you.
Everybody
for
coming
to
this
I
hope
that
I
met
you
at
the
right
level
of
high
level
low
level.
There
was
some
code
links.
There
were
some
high
level
discussions
of
deprecating
things,
so
I
hope
that
people
learn
some
things
or
just
remembered
some
things.
A
H
You
just
one
one
reminder:
We
Fall,
River
closing
for
the
team
members.
The
engineers
remember
that
we
have
this
Prague
get
together,
so
that
negotia
is
helping
to
organize
I
know
that
imbre
has
already
booked
a
hotel,
I'm
planning
to
do
it
today.
So
I
think
it
will
be
fun
to
see
each
other
I,
don't
know
about
you,
Manor.
If
you
are
planning
to
come,
or
if
you
have
here
but
or
others,
it
will
be
too
too
far.
Maybe.