Emixa Mendix Meetup 11 April 2024 about Mendix Native development
OAuth 2.0 Reference Model for API Management
1. OAuth
2.0
Reference
Model
for
API
Management
Sumedha
Rubasinghe
Senior
Architect,
WSO2
API
Manager
Team
2. About
WSO2
๏
๏
Global
enterprise,
founded
in
2005
by
acknowledged
leaders
in
XML,
web
services
technologies,
standards
and
open
source
Provides
only
open
source
pla:orm-‐as-‐a-‐service
for
private,
public
and
hybrid
cloud
deployments
๏
๏
*
All
WSO2
products
are
100%
open
source
and
released
under
the
Apache
License
Version
2.0.
Is
an
AcIve
Member
of
OASIS,
Cloud
Security
Alliance,
OSGi
Alliance,
AMQP
Working
Group,
OpenID
FoundaIon
and
W3C.
๏ Driven
by
InnovaIon
๏ Launched
first
open
source
API
Management
soluIon
in
2012
๏ Launched
App
Factory
in
2Q
2013
๏ Launched
Enterprise
Store
and
first
open
source
Mobile
soluIon
in
4Q
2013
4. What
we
will
cover...
● Main
concepts
in
OAuth
2.0
model
● How
WSO2
supports
OAuth
2.0
based
API
Management?
● OAuth
2.0
based
extensions
in
WSO2
API
Management
soluIon
*
5. Web
(based)
APIs
● hXps://www.facebook.com/sam.jason/photos
● hXp://api-‐public.ne:lix.com/catalog/Itles/movies/60021896
● many
more..
*
8. Pre
OAuth
Era
..
No
Control
over
password
storage.
Complete
access
to
user
account.
*
ApplicaIons
can
be
compromised.
Changing
password
can
break
many
apps.
Requires
password
reset
to
revoke.
9. OAuth
2.0
-‐
in
a
nutshell..
“The
OAuth
2.0
authorizaIon
framework
enables
a
third-‐party
applica2on
to
obtain
limited
access
to
an
HTTP
service…”
-‐OAuth
2.0
SpecificaKon,
hLp://tools.ieO.org/html/rfc6749
*
10. WSO2
API
Manager
● Complete
API
Management
Pla:orm
○
○
○
○
○
○
○
○
API
Publishing
API
Store
SubscripIon
Mgt
Token
Management
ThroXling
StaIsIcs
Scalable
Deployment
OAuth
2.0
based
● Apache
v2
Licensed
● Build
on
top
of
proven
WSO2
components
*
○ Enterprise
Service
Bus
○ IdenIty
Server
○ Governance
Registry
● hXp://docs.wso2.org/display/AM160/WSO2+API+Manager
11. OAuth
2.0
-‐
DefiniKons
*
● Resource
Owner
○ EnIty(end
user)
capable
of
granIng
access
to
a
resource
○ FB
user
(enIty)
-‐>
hXps://www.facebook.com/search/me/friends
(resource)
● Resource
Server
(hXps://www.facebook.com)
○ Server
hosIng
protected
resources
○ Capable
of
accepIng
and
responding
to
resource
requests
● Client
(FB
applicaIon)
○ ApplicaIon
making
requests
to
access
protected
resources
● Authoriza2on
Server
(can
be
same
as
Resource
Server)
○ Server
issuing
access
tokens
to
the
client
14. AuthorizaKon
Code
● End
user
visits
auth
page
○ response_type=code
Web
Server
Apps
● End
user
is
redirected
to
your
site
with
auth
code
○ http://yoursite.com/?code=xxxxxx
● Web
Server
exchanges
Auth
Code
for
an
Access
Token
○ POST /token
code=xxxxxx&grant_type=authorization_code
*
19. Implicit
Grant
● Browser
based
apps
■ no
server
side
code
■ browser
makes
API
requests
directly
● User
visits
a
page
○ response_type=token
Browser
based
Apps
● User
is
redirected
to
your
site
with
access
token
○ http://yoursite.com/#token=xxxxxx
● Token
is
only
available
to
browser
(only
in
fragment)
*
20. Implicit
Grant
-‐
Syntax
Browser
based
Apps
hLp://docs.wso2.org/display/AM160/Token+API
*
21. Password
Grant
Trusted
ApplicaKons
● Only
by
trusted
clients
○ Apps
&
APIs
-‐
by
same
enterprise
/First
party
Apps
hLp://docs.wso2.org/display/AM160/Token+API
*
22. Client
CredenKals
ApplicaKons
● ApplicaIon
level
access
● ApplicaIon
has
○ client_id
(consumer
key)
○ client_secret
(consumer
secret)
● Server
uses
client_id
&
client_secret
to
obtain
access
token
○ POST
/token
grant_type=client_credenIals&client_id=XXXX&client_secret=
YYYY
*
24. Mobile
ApplicaKons
● Use
‘implicit’
grant
type
○ (similar
to
browser
based
apps)
● Mobile
App
directly
does
API
calls
● No
client
(mobile
app)
secret
● NaIve
App
-‐>
Browser
based
call
*
Mobile
Apps
26. Grant
Type
Summary
● authorizaKon_code
○ Web
Server
based
applicaIons
● implicit
○ Browser
based
applicaIons,
Mobile
Apps
● password
○ username/password
based
access
● client
_credenKals
○ ApplicaIons
(with
no
need
of
user
level
authorizaIon)
*
31. Bearer
Tokens
● Security
ConsideraIons
○ Replies
on
transport
level
security
(HTTPS)
○ No
cryptographic
verificaIon
● Security
RecommendaIons
○ Use
HTTPs
(always)
&
verify
SSL
CerIficates
○ Protect
Bearer
tokens
○ Choose
token
lifeIme
wisely
○ Do
not
persist
tokens
unnecessarily
*
32. MAC
Tokens
● Provides
cryptographic
verificaIon
of
request
*
33. LimiKng
Access
through
‘scope'
● ‘scope’
-‐>
specifies
what
needs
be
done
with
the
access
token
● Specified
@
the
point
of
obtaining
access
token
● space
delimited,
comma
delimited
string
● eg:
Facebook
Extended
Permissions
○ hXps://developers.facebook.com/docs/reference/login/
extended-‐permissions/
*
34. “scope”
-‐
Facebook
Example
hXps://developers.facebook.com/docs/reference/login/extended-‐permissions/
*