Mixing
Securing web app and api using OpenID Connect
I don't want to roll my own security anymore and am looking at using OpenID Connect with my c# API and AngularJS app. I can get all that to work just fine. However, my brain cannot seem to understand how to secure my API correctly for both use cases:
Use Case 1: AngularJS SPA
My AngularJS app connects to my API and sends a bearer token identifying the user and includes user claims. This one is easy and there is tons of documentation on it.
Use Case 2: API to API
Some customers want to access my API directly instead of going through my AngularJS app. In this case, I thought I could use a Client ID/Secret for toen-based authentication which is great except then I know nothing about the user that's using the client id/secret. There could be 10 users using the same custom API that is calling my API. How do I get user info via the API call? I've seen others use API keys that they then lookup the user and create a JWT but I thought there might be an easier way. Any ideas?
access-token openid-connect
asked Jan 2 at 23:10
206mph206mph
96112
add a comment |
I don't want to roll my own security anymore and am looking at using OpenID Connect with my c# API and AngularJS app. I can get all that to work just fine. However, my brain cannot seem to understand how to secure my API correctly for both use cases:
Use Case 1: AngularJS SPA
My AngularJS app connects to my API and sends a bearer token identifying the user and includes user claims. This one is easy and there is tons of documentation on it.
Use Case 2: API to API
Some customers want to access my API directly instead of going through my AngularJS app. In this case, I thought I could use a Client ID/Secret for toen-based authentication which is great except then I know nothing about the user that's using the client id/secret. There could be 10 users using the same custom API that is calling my API. How do I get user info via the API call? I've seen others use API keys that they then lookup the user and create a JWT but I thought there might be an easier way. Any ideas?
access-token openid-connect
asked Jan 2 at 23:10
206mph206mph
96112
To answer your question re: use case 2, I need more context. a) Do you need to know who is the user that authorizing the access to the API? b) Are the APP and the user one-to-one or one-to-many? c) Who is maintaining the user credentials and registry? d) Why do these customers want to access your API "Directly"? Do they want to avoid even a single set-up where the user authorizes the subsequent access?
– Nat Sakimura
Jan 10 at 8:24
add a comment |
I don't want to roll my own security anymore and am looking at using OpenID Connect with my c# API and AngularJS app. I can get all that to work just fine. However, my brain cannot seem to understand how to secure my API correctly for both use cases:
Use Case 1: AngularJS SPA
My AngularJS app connects to my API and sends a bearer token identifying the user and includes user claims. This one is easy and there is tons of documentation on it.
Use Case 2: API to API
Some customers want to access my API directly instead of going through my AngularJS app. In this case, I thought I could use a Client ID/Secret for toen-based authentication which is great except then I know nothing about the user that's using the client id/secret. There could be 10 users using the same custom API that is calling my API. How do I get user info via the API call? I've seen others use API keys that they then lookup the user and create a JWT but I thought there might be an easier way. Any ideas?
access-token openid-connect
asked Jan 2 at 23:10
206mph206mph
96112
I don't want to roll my own security anymore and am looking at using OpenID Connect with my c# API and AngularJS app. I can get all that to work just fine. However, my brain cannot seem to understand how to secure my API correctly for both use cases:
Use Case 1: AngularJS SPA
My AngularJS app connects to my API and sends a bearer token identifying the user and includes user claims. This one is easy and there is tons of documentation on it.
Use Case 2: API to API
Some customers want to access my API directly instead of going through my AngularJS app. In this case, I thought I could use a Client ID/Secret for toen-based authentication which is great except then I know nothing about the user that's using the client id/secret. There could be 10 users using the same custom API that is calling my API. How do I get user info via the API call? I've seen others use API keys that they then lookup the user and create a JWT but I thought there might be an easier way. Any ideas?
access-token openid-connect
access-token openid-connect
asked Jan 2 at 23:10
206mph206mph
96112
asked Jan 2 at 23:10
206mph206mph
96112
asked Jan 2 at 23:10
206mph206mph
96112
asked Jan 2 at 23:10
206mph206mph
96112
asked Jan 2 at 23:10
206mph206mph
96112
96112
To answer your question re: use case 2, I need more context. a) Do you need to know who is the user that authorizing the access to the API? b) Are the APP and the user one-to-one or one-to-many? c) Who is maintaining the user credentials and registry? d) Why do these customers want to access your API "Directly"? Do they want to avoid even a single set-up where the user authorizes the subsequent access?
– Nat Sakimura
Jan 10 at 8:24
add a comment |
To answer your question re: use case 2, I need more context. a) Do you need to know who is the user that authorizing the access to the API? b) Are the APP and the user one-to-one or one-to-many? c) Who is maintaining the user credentials and registry? d) Why do these customers want to access your API "Directly"? Do they want to avoid even a single set-up where the user authorizes the subsequent access?
– Nat Sakimura
Jan 10 at 8:24
To answer your question re: use case 2, I need more context. a) Do you need to know who is the user that authorizing the access to the API? b) Are the APP and the user one-to-one or one-to-many? c) Who is maintaining the user credentials and registry? d) Why do these customers want to access your API "Directly"? Do they want to avoid even a single set-up where the user authorizes the subsequent access?
– Nat Sakimura
Jan 10 at 8:24
To answer your question re: use case 2, I need more context. a) Do you need to know who is the user that authorizing the access to the API? b) Are the APP and the user one-to-one or one-to-many? c) Who is maintaining the user credentials and registry? d) Why do these customers want to access your API "Directly"? Do they want to avoid even a single set-up where the user authorizes the subsequent access?
– Nat Sakimura
Jan 10 at 8:24
add a comment |
2 Answers
2
active
oldest
votes
The whole point of API to API authentication is that there is no user context. Or well, the user in that case is the machine trying to access your API. You would then need to design your authorization logic around that and implement scope based permissions. Alternatively, your options are to use api keys as you mentioned or if you want OAuth protocol with user context in the api to api scenario - then ResourceOwnerCredentials flow is an option.
answered Jan 3 at 1:57
Vidmantas BlazeviciusVidmantas Blazevicius
2,3482419
1
ROPC definitely is not an option here. Also, support for user-not-in-presence (which is one of the main reason for API) and no-user-context is quite a different thing. There are many APIs that require user context as it is often the case that the API needs to know under whose authorization the access is being granted.
– Nat Sakimura
Jan 10 at 8:21
add a comment |
API to API communcation
You can use Client Credentials Grant defined through OAuth 2.0. This won't require you to have end user credentials. Now this won't be OpenID Connect. OpenID Connect require the involvement of an end user and bound to authentication. OAuth 2.0 on the other hand is about authorization, checking whether the entity can access the resource.
With Client Credential Grant, your identity server will issue tokens for a specific client. So one of your API becomes the client (resource consumer). From request handling API endpoint, you can accept valid tokens and respond back with resource.
If you require fine grained access control from request handling API, you will require to use token introspection to identify to whom this token was issued. In this case, it will be identification of specific client identity and execute a logic on top of it. You can check the token introspection response to identify such details.
Alternatively, access tokens can be come in form of a JWT. If this is the case, they can be considered as self contained tokens so validation is straightforward.
answered Jan 3 at 3:27
Kavindu DodanduwaKavindu Dodanduwa
6,22621734
This barely answers the OP's question and in fact contains inaccurate things like token introspection which are irrelevant and doesn't help because the token already identifies to whom it's been issued via appropriate claims and introspection only allows to re verify that the token is indeed valid.
– Vidmantas Blazevicius
Jan 3 at 10:12
@VidmantasBlazevicius Mind you what you are talking. How do you find claims in an access token if it is opaque ? Well, I believe you haven't read and understood what token introspection endpoint is used for. And you are talking from OpenID connect perspective, which is irrelevant as OP is talking about client to client (API - API) communication
– Kavindu Dodanduwa
Jan 3 at 10:29
@VidmantasBlazevicius also, please explain how you do " the token already identifies to whom it's been issued via appropriate claims" ? I would be really grateful to know your approach.
– Kavindu Dodanduwa
Jan 3 at 10:30
Usually via client_id claim to identify which client it has been issued to or subjectid claim for the openidc flows. Perhaps you are talking about UserInfo endpoints to which you send identity tokens and get back user claims? Introspection really usually is meant to serve purpose of validating whether the token is valid and active.
– Vidmantas Blazevicius
Jan 3 at 11:05
@VidmantasBlazevicius well, your explanation is about authorization server. It can validate client through client_id parameter. But once you got hold of access token, how will you say to which client it belongs to ? Specially when access token is opaque. That's where token introspection comes into picture. Also, userinfo endpoint is invoked with access token and it is to identify end user details. But for an API to API communication, end user is not mandatory. That's why OAuth 2.0 can be used here. Please go through specifications to understand core of the issue.
– Kavindu Dodanduwa
Jan 3 at 12:03
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54014363%2fsecuring-web-app-and-api-using-openid-connect%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The whole point of API to API authentication is that there is no user context. Or well, the user in that case is the machine trying to access your API. You would then need to design your authorization logic around that and implement scope based permissions. Alternatively, your options are to use api keys as you mentioned or if you want OAuth protocol with user context in the api to api scenario - then ResourceOwnerCredentials flow is an option.
answered Jan 3 at 1:57
Vidmantas BlazeviciusVidmantas Blazevicius
2,3482419
1
ROPC definitely is not an option here. Also, support for user-not-in-presence (which is one of the main reason for API) and no-user-context is quite a different thing. There are many APIs that require user context as it is often the case that the API needs to know under whose authorization the access is being granted.
– Nat Sakimura
Jan 10 at 8:21
add a comment |
The whole point of API to API authentication is that there is no user context. Or well, the user in that case is the machine trying to access your API. You would then need to design your authorization logic around that and implement scope based permissions. Alternatively, your options are to use api keys as you mentioned or if you want OAuth protocol with user context in the api to api scenario - then ResourceOwnerCredentials flow is an option.
answered Jan 3 at 1:57
Vidmantas BlazeviciusVidmantas Blazevicius
2,3482419
1
ROPC definitely is not an option here. Also, support for user-not-in-presence (which is one of the main reason for API) and no-user-context is quite a different thing. There are many APIs that require user context as it is often the case that the API needs to know under whose authorization the access is being granted.
– Nat Sakimura
Jan 10 at 8:21
add a comment |
The whole point of API to API authentication is that there is no user context. Or well, the user in that case is the machine trying to access your API. You would then need to design your authorization logic around that and implement scope based permissions. Alternatively, your options are to use api keys as you mentioned or if you want OAuth protocol with user context in the api to api scenario - then ResourceOwnerCredentials flow is an option.
answered Jan 3 at 1:57
Vidmantas BlazeviciusVidmantas Blazevicius
2,3482419
The whole point of API to API authentication is that there is no user context. Or well, the user in that case is the machine trying to access your API. You would then need to design your authorization logic around that and implement scope based permissions. Alternatively, your options are to use api keys as you mentioned or if you want OAuth protocol with user context in the api to api scenario - then ResourceOwnerCredentials flow is an option.
answered Jan 3 at 1:57
Vidmantas BlazeviciusVidmantas Blazevicius
2,3482419
answered Jan 3 at 1:57
Vidmantas BlazeviciusVidmantas Blazevicius
2,3482419
answered Jan 3 at 1:57
Vidmantas BlazeviciusVidmantas Blazevicius
2,3482419
answered Jan 3 at 1:57
Vidmantas BlazeviciusVidmantas Blazevicius
2,3482419
2,3482419
1
ROPC definitely is not an option here. Also, support for user-not-in-presence (which is one of the main reason for API) and no-user-context is quite a different thing. There are many APIs that require user context as it is often the case that the API needs to know under whose authorization the access is being granted.
– Nat Sakimura
Jan 10 at 8:21
add a comment |
1
ROPC definitely is not an option here. Also, support for user-not-in-presence (which is one of the main reason for API) and no-user-context is quite a different thing. There are many APIs that require user context as it is often the case that the API needs to know under whose authorization the access is being granted.
– Nat Sakimura
Jan 10 at 8:21
1
1
ROPC definitely is not an option here. Also, support for user-not-in-presence (which is one of the main reason for API) and no-user-context is quite a different thing. There are many APIs that require user context as it is often the case that the API needs to know under whose authorization the access is being granted.
– Nat Sakimura
Jan 10 at 8:21
ROPC definitely is not an option here. Also, support for user-not-in-presence (which is one of the main reason for API) and no-user-context is quite a different thing. There are many APIs that require user context as it is often the case that the API needs to know under whose authorization the access is being granted.
– Nat Sakimura
Jan 10 at 8:21
add a comment |
API to API communcation
You can use Client Credentials Grant defined through OAuth 2.0. This won't require you to have end user credentials. Now this won't be OpenID Connect. OpenID Connect require the involvement of an end user and bound to authentication. OAuth 2.0 on the other hand is about authorization, checking whether the entity can access the resource.
With Client Credential Grant, your identity server will issue tokens for a specific client. So one of your API becomes the client (resource consumer). From request handling API endpoint, you can accept valid tokens and respond back with resource.
If you require fine grained access control from request handling API, you will require to use token introspection to identify to whom this token was issued. In this case, it will be identification of specific client identity and execute a logic on top of it. You can check the token introspection response to identify such details.
Alternatively, access tokens can be come in form of a JWT. If this is the case, they can be considered as self contained tokens so validation is straightforward.
answered Jan 3 at 3:27
Kavindu DodanduwaKavindu Dodanduwa
6,22621734
This barely answers the OP's question and in fact contains inaccurate things like token introspection which are irrelevant and doesn't help because the token already identifies to whom it's been issued via appropriate claims and introspection only allows to re verify that the token is indeed valid.
– Vidmantas Blazevicius
Jan 3 at 10:12
@VidmantasBlazevicius Mind you what you are talking. How do you find claims in an access token if it is opaque ? Well, I believe you haven't read and understood what token introspection endpoint is used for. And you are talking from OpenID connect perspective, which is irrelevant as OP is talking about client to client (API - API) communication
– Kavindu Dodanduwa
Jan 3 at 10:29
@VidmantasBlazevicius also, please explain how you do " the token already identifies to whom it's been issued via appropriate claims" ? I would be really grateful to know your approach.
– Kavindu Dodanduwa
Jan 3 at 10:30
Usually via client_id claim to identify which client it has been issued to or subjectid claim for the openidc flows. Perhaps you are talking about UserInfo endpoints to which you send identity tokens and get back user claims? Introspection really usually is meant to serve purpose of validating whether the token is valid and active.
– Vidmantas Blazevicius
Jan 3 at 11:05
@VidmantasBlazevicius well, your explanation is about authorization server. It can validate client through client_id parameter. But once you got hold of access token, how will you say to which client it belongs to ? Specially when access token is opaque. That's where token introspection comes into picture. Also, userinfo endpoint is invoked with access token and it is to identify end user details. But for an API to API communication, end user is not mandatory. That's why OAuth 2.0 can be used here. Please go through specifications to understand core of the issue.
– Kavindu Dodanduwa
Jan 3 at 12:03
add a comment |
API to API communcation
You can use Client Credentials Grant defined through OAuth 2.0. This won't require you to have end user credentials. Now this won't be OpenID Connect. OpenID Connect require the involvement of an end user and bound to authentication. OAuth 2.0 on the other hand is about authorization, checking whether the entity can access the resource.
With Client Credential Grant, your identity server will issue tokens for a specific client. So one of your API becomes the client (resource consumer). From request handling API endpoint, you can accept valid tokens and respond back with resource.
If you require fine grained access control from request handling API, you will require to use token introspection to identify to whom this token was issued. In this case, it will be identification of specific client identity and execute a logic on top of it. You can check the token introspection response to identify such details.
Alternatively, access tokens can be come in form of a JWT. If this is the case, they can be considered as self contained tokens so validation is straightforward.
answered Jan 3 at 3:27
Kavindu DodanduwaKavindu Dodanduwa
6,22621734
This barely answers the OP's question and in fact contains inaccurate things like token introspection which are irrelevant and doesn't help because the token already identifies to whom it's been issued via appropriate claims and introspection only allows to re verify that the token is indeed valid.
– Vidmantas Blazevicius
Jan 3 at 10:12
@VidmantasBlazevicius Mind you what you are talking. How do you find claims in an access token if it is opaque ? Well, I believe you haven't read and understood what token introspection endpoint is used for. And you are talking from OpenID connect perspective, which is irrelevant as OP is talking about client to client (API - API) communication
– Kavindu Dodanduwa
Jan 3 at 10:29
@VidmantasBlazevicius also, please explain how you do " the token already identifies to whom it's been issued via appropriate claims" ? I would be really grateful to know your approach.
– Kavindu Dodanduwa
Jan 3 at 10:30
Usually via client_id claim to identify which client it has been issued to or subjectid claim for the openidc flows. Perhaps you are talking about UserInfo endpoints to which you send identity tokens and get back user claims? Introspection really usually is meant to serve purpose of validating whether the token is valid and active.
– Vidmantas Blazevicius
Jan 3 at 11:05
@VidmantasBlazevicius well, your explanation is about authorization server. It can validate client through client_id parameter. But once you got hold of access token, how will you say to which client it belongs to ? Specially when access token is opaque. That's where token introspection comes into picture. Also, userinfo endpoint is invoked with access token and it is to identify end user details. But for an API to API communication, end user is not mandatory. That's why OAuth 2.0 can be used here. Please go through specifications to understand core of the issue.
– Kavindu Dodanduwa
Jan 3 at 12:03
add a comment |
API to API communcation
You can use Client Credentials Grant defined through OAuth 2.0. This won't require you to have end user credentials. Now this won't be OpenID Connect. OpenID Connect require the involvement of an end user and bound to authentication. OAuth 2.0 on the other hand is about authorization, checking whether the entity can access the resource.
With Client Credential Grant, your identity server will issue tokens for a specific client. So one of your API becomes the client (resource consumer). From request handling API endpoint, you can accept valid tokens and respond back with resource.
If you require fine grained access control from request handling API, you will require to use token introspection to identify to whom this token was issued. In this case, it will be identification of specific client identity and execute a logic on top of it. You can check the token introspection response to identify such details.
Alternatively, access tokens can be come in form of a JWT. If this is the case, they can be considered as self contained tokens so validation is straightforward.
answered Jan 3 at 3:27
Kavindu DodanduwaKavindu Dodanduwa
6,22621734
API to API communcation
You can use Client Credentials Grant defined through OAuth 2.0. This won't require you to have end user credentials. Now this won't be OpenID Connect. OpenID Connect require the involvement of an end user and bound to authentication. OAuth 2.0 on the other hand is about authorization, checking whether the entity can access the resource.
With Client Credential Grant, your identity server will issue tokens for a specific client. So one of your API becomes the client (resource consumer). From request handling API endpoint, you can accept valid tokens and respond back with resource.
If you require fine grained access control from request handling API, you will require to use token introspection to identify to whom this token was issued. In this case, it will be identification of specific client identity and execute a logic on top of it. You can check the token introspection response to identify such details.
Alternatively, access tokens can be come in form of a JWT. If this is the case, they can be considered as self contained tokens so validation is straightforward.
answered Jan 3 at 3:27
Kavindu DodanduwaKavindu Dodanduwa
6,22621734
edited Jan 3 at 3:34
answered Jan 3 at 3:27
Kavindu DodanduwaKavindu Dodanduwa
6,22621734
answered Jan 3 at 3:27
Kavindu DodanduwaKavindu Dodanduwa
6,22621734
answered Jan 3 at 3:27
Kavindu DodanduwaKavindu Dodanduwa
6,22621734
6,22621734
This barely answers the OP's question and in fact contains inaccurate things like token introspection which are irrelevant and doesn't help because the token already identifies to whom it's been issued via appropriate claims and introspection only allows to re verify that the token is indeed valid.
– Vidmantas Blazevicius
Jan 3 at 10:12
@VidmantasBlazevicius Mind you what you are talking. How do you find claims in an access token if it is opaque ? Well, I believe you haven't read and understood what token introspection endpoint is used for. And you are talking from OpenID connect perspective, which is irrelevant as OP is talking about client to client (API - API) communication
– Kavindu Dodanduwa
Jan 3 at 10:29
@VidmantasBlazevicius also, please explain how you do " the token already identifies to whom it's been issued via appropriate claims" ? I would be really grateful to know your approach.
– Kavindu Dodanduwa
Jan 3 at 10:30
Usually via client_id claim to identify which client it has been issued to or subjectid claim for the openidc flows. Perhaps you are talking about UserInfo endpoints to which you send identity tokens and get back user claims? Introspection really usually is meant to serve purpose of validating whether the token is valid and active.
– Vidmantas Blazevicius
Jan 3 at 11:05
@VidmantasBlazevicius well, your explanation is about authorization server. It can validate client through client_id parameter. But once you got hold of access token, how will you say to which client it belongs to ? Specially when access token is opaque. That's where token introspection comes into picture. Also, userinfo endpoint is invoked with access token and it is to identify end user details. But for an API to API communication, end user is not mandatory. That's why OAuth 2.0 can be used here. Please go through specifications to understand core of the issue.
– Kavindu Dodanduwa
Jan 3 at 12:03
add a comment |
This barely answers the OP's question and in fact contains inaccurate things like token introspection which are irrelevant and doesn't help because the token already identifies to whom it's been issued via appropriate claims and introspection only allows to re verify that the token is indeed valid.
– Vidmantas Blazevicius
Jan 3 at 10:12
@VidmantasBlazevicius Mind you what you are talking. How do you find claims in an access token if it is opaque ? Well, I believe you haven't read and understood what token introspection endpoint is used for. And you are talking from OpenID connect perspective, which is irrelevant as OP is talking about client to client (API - API) communication
– Kavindu Dodanduwa
Jan 3 at 10:29
@VidmantasBlazevicius also, please explain how you do " the token already identifies to whom it's been issued via appropriate claims" ? I would be really grateful to know your approach.
– Kavindu Dodanduwa
Jan 3 at 10:30
Usually via client_id claim to identify which client it has been issued to or subjectid claim for the openidc flows. Perhaps you are talking about UserInfo endpoints to which you send identity tokens and get back user claims? Introspection really usually is meant to serve purpose of validating whether the token is valid and active.
– Vidmantas Blazevicius
Jan 3 at 11:05
@VidmantasBlazevicius well, your explanation is about authorization server. It can validate client through client_id parameter. But once you got hold of access token, how will you say to which client it belongs to ? Specially when access token is opaque. That's where token introspection comes into picture. Also, userinfo endpoint is invoked with access token and it is to identify end user details. But for an API to API communication, end user is not mandatory. That's why OAuth 2.0 can be used here. Please go through specifications to understand core of the issue.
– Kavindu Dodanduwa
Jan 3 at 12:03
This barely answers the OP's question and in fact contains inaccurate things like token introspection which are irrelevant and doesn't help because the token already identifies to whom it's been issued via appropriate claims and introspection only allows to re verify that the token is indeed valid.
– Vidmantas Blazevicius
Jan 3 at 10:12
This barely answers the OP's question and in fact contains inaccurate things like token introspection which are irrelevant and doesn't help because the token already identifies to whom it's been issued via appropriate claims and introspection only allows to re verify that the token is indeed valid.
– Vidmantas Blazevicius
Jan 3 at 10:12
@VidmantasBlazevicius Mind you what you are talking. How do you find claims in an access token if it is opaque ? Well, I believe you haven't read and understood what token introspection endpoint is used for. And you are talking from OpenID connect perspective, which is irrelevant as OP is talking about client to client (API - API) communication
– Kavindu Dodanduwa
Jan 3 at 10:29
@VidmantasBlazevicius Mind you what you are talking. How do you find claims in an access token if it is opaque ? Well, I believe you haven't read and understood what token introspection endpoint is used for. And you are talking from OpenID connect perspective, which is irrelevant as OP is talking about client to client (API - API) communication
– Kavindu Dodanduwa
Jan 3 at 10:29
@VidmantasBlazevicius also, please explain how you do " the token already identifies to whom it's been issued via appropriate claims" ? I would be really grateful to know your approach.
– Kavindu Dodanduwa
Jan 3 at 10:30
@VidmantasBlazevicius also, please explain how you do " the token already identifies to whom it's been issued via appropriate claims" ? I would be really grateful to know your approach.
– Kavindu Dodanduwa
Jan 3 at 10:30
Usually via client_id claim to identify which client it has been issued to or subjectid claim for the openidc flows. Perhaps you are talking about UserInfo endpoints to which you send identity tokens and get back user claims? Introspection really usually is meant to serve purpose of validating whether the token is valid and active.
– Vidmantas Blazevicius
Jan 3 at 11:05
Usually via client_id claim to identify which client it has been issued to or subjectid claim for the openidc flows. Perhaps you are talking about UserInfo endpoints to which you send identity tokens and get back user claims? Introspection really usually is meant to serve purpose of validating whether the token is valid and active.
– Vidmantas Blazevicius
Jan 3 at 11:05
@VidmantasBlazevicius well, your explanation is about authorization server. It can validate client through client_id parameter. But once you got hold of access token, how will you say to which client it belongs to ? Specially when access token is opaque. That's where token introspection comes into picture. Also, userinfo endpoint is invoked with access token and it is to identify end user details. But for an API to API communication, end user is not mandatory. That's why OAuth 2.0 can be used here. Please go through specifications to understand core of the issue.
– Kavindu Dodanduwa
Jan 3 at 12:03
@VidmantasBlazevicius well, your explanation is about authorization server. It can validate client through client_id parameter. But once you got hold of access token, how will you say to which client it belongs to ? Specially when access token is opaque. That's where token introspection comes into picture. Also, userinfo endpoint is invoked with access token and it is to identify end user details. But for an API to API communication, end user is not mandatory. That's why OAuth 2.0 can be used here. Please go through specifications to understand core of the issue.
– Kavindu Dodanduwa
Jan 3 at 12:03
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54014363%2fsecuring-web-app-and-api-using-openid-connect%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
To answer your question re: use case 2, I need more context. a) Do you need to know who is the user that authorizing the access to the API? b) Are the APP and the user one-to-one or one-to-many? c) Who is maintaining the user credentials and registry? d) Why do these customers want to access your API "Directly"? Do they want to avoid even a single set-up where the user authorizes the subsequent access?
– Nat Sakimura
Jan 10 at 8:24