OAuth and OpenID Connect for Microservices
Why Stack Overflow recommends it
Stack Overflow users link it when explaining how OAuth2 authorization differs from OpenID Connect authentication, and how tokens should be used across microservices.
Recommended by 3 people across 6 different months, 2016 to 2021.
What it is
A conference talk by Jacob Ideskog of Curity at Nordic APIs' 2014 Platform Summit in Stockholm. It explains how OAuth and OpenID Connect can give microservice architectures a unified, distributed way to handle security while keeping their agility and scalability.
What people said
Strong rec Spomky-Labs · 2017-05 · Stack Overflow · on “OAuth2 not for authentication”
The access token you receive just represents an authorization issued to the client. It just allows the client to access on protected resources, but it does not give you any information about the resource owner. In your example, evil.com can get those resources that own the userA, but cannot know who userA is. Please loook at this excellent video [this video] about OAuth2 and the Authorization/Authentication terms. It helped me a lot.
Recommends Spomky-Labs · 2016-02 · Stack Overflow · on “Secure third-party API calls on mobile app”
In your case, your approach with OAuth2 is good: mobile apps (clients) receive delegation from resource owners (your users) to call protected resources on a resource server (your API). You only have information about your clients because OAuth2 is not dedicated to authentication of your users but authorization of you clients. The clients are identified with a client ID. In your case and if you want to know which client calls your resource server, then each client should have a dedicated client ID. You may also identify it using other information such as the IP address or a custom header in the requests it sends. If you want to know who your users are, you should implement the OpenID Connect
Recommends Spomky-Labs · 2016-03 · Stack Overflow · on “Problems understanding how OAuth 2.0 and OpenID Connect work together”
And there is an excellent video where the both protocols are explained [this video] (especially from 4:44 to 11:00).
Recommends Noah · 2016-08 · Stack Overflow · on “Azure AD B2C with Angular 2”
1 -2 When the token expires it can be auto renewed without the user having to re-enter their credentials on Azure. I don't see any reason why you shouldn't use Azure B2c in production. It is in general availability and production ready. As Azure AD B2C is an implementation of Open ID you may benefit from getting an overview of Open ID. There are may resources on the internet. Here is a quick overview video. [this video]
Recommends cassandrad · 2016-10 · Stack Overflow · on “Microservices Authentication best practices and security (OAuth 2.0 and OpenIdConnect)”
Regarding by-reference/by-value question: have you watched the video [this video] placed near the text you are citing?
Recommends Spomky-Labs · 2016-12 · Stack Overflow · on “OAuth vs OpenID: confused about when to use one of these and why”
You are right: lot of authorization servers based on OAuth2 provides a way to authenticate. But OAuth2 is not designed for that purpose. In an OAuth2 context, the client has just an access token to retrieve/manage resources on a resource server. It knows nothing about the resource owner. That is why the OpenID Connect protocol has been created. It works on top of the OAuth2 Framework protocol and allows the client to get information about the resource owner. I recommend you to look at this very interesting talk [this video] (start at 4:44). This video helped me a lot to understand the purpose of each token. I hope it will help you too.
Cites Spomky-Labs · 2017-07 · Stack Overflow · on “Prevent users to have multiple sessions with JWT Tokens”
@Mardoxx is right. For more information see [this video] In other words: the feature you want to implement is not acheivable with JWT unless you add a token revocation support. If you do so then you will loose the main benefit of the JWT (stateless) hence reference tokens should be used.
Cites Travis Spencer · 2021-01 · Stack Overflow · on “OIDC - Obtaining an Identity Token for use by a backend (no actual user) service running scheduled jobs”
Let me start by saying, I wouldn't recommend the architecture you have. So, I'll give you two answers: a short-term practical one and a medium-term one that will result in a more ideal system. First, the quick fix: turn on basic auth in the API. Then, call your API from the scheduled task runner using basic auth and a long secret, like this: Authorization: basic bXktZ29vZC1zZXJ2aWNlOkY2M0JEOTkyLTMzNTUtNDYzNi1CNzFBLTM3RDg0QzI3ODEzRQo= Then, keep validating the ID token you get from the SPA. I am assuming you're sending this to the API using the technique described in RFC 6750: Authorization: bearer eyJhbGciOiJSUzI1NiJ9.ey... So, these two different authentication methods make it easy for the