Identity Server 4 Protect an API











up vote
0
down vote

favorite
1












I'm trying to use Identity Server 4 to protect my API. Now I have gone through all the documentation at http://docs.identityserver.io/en/release/quickstarts/1_client_credentials.html and I have set up a few successful demos. However, there is one thing that I am failing to understand.



For example, First, we need to define a client on the IS4 that looks like this:



new Client
{
ClientId = "client",

// no interactive user, use the clientid/secret for authentication
AllowedGrantTypes = GrantTypes.ClientCredentials,

// secret for authentication
ClientSecrets =
{
new Secret("secret".Sha256())
},

// scopes that client has access to
AllowedScopes = { "api1" }
}


Then on the API we protect it by adding the IdentityServer4.AccessTokenValidation package and adding configuration to startup.cs



services.AddMvcCore()
.AddAuthorization()
.AddJsonFormatters();

services.AddAuthentication("Bearer")
.AddIdentityServerAuthentication(options =>
{
options.Authority = "http://localhost:5000";
options.RequireHttpsMetadata = false;

options.ApiName = "api1";
});


And then finally we add app.UseAuthentication();



Now, this all works when ran, however, the part that I don't understand is where is the secret defined in the API. As you can see, the client clearly expects a secret and yet I don't define this secret anywhere on my API. I also don't define anywhere on the IS4 anything about my API to say that you are protecting the API from this URI or something along those lines.



So how does this actually works in terms of IS4 knowing about the API and authenticating its requests?



EDIT:



To clarify some confusion, yes there is a client that I opted out in code above and I see now that I shouldn't, and in there I provide a secret, but I'm still not understanding how does the IS4 knows to protect my specific API. What if the request came from www.somerandomapi.com? From what I"m reading it would work regardless. Based on what you wrote, it does make sense that the client is passing the secret, but nowhere in my code is the IS4 told which API to protect.










share|improve this question
























  • The secret is passed in from the client (docs.identityserver.io/en/release/quickstarts/…)
    – DavidG
    Nov 19 at 15:32






  • 2




    @CamiloTerevinto The client is passing in the secret though, that's how it get the bearer access token. The code works fine.
    – DavidG
    Nov 19 at 15:34








  • 2




    @CamiloTerevinto But that's how it works! The code above doesn't show the flow, just the setup. The question "where is the secret defined in the API" is meaningless - it's not defined there at all.
    – DavidG
    Nov 19 at 15:36








  • 1




    The API doesn't need a secret at all, as has been said. However, any client that wants to consume your API either needs a secret or a preregistered redirect url, for example, in order to get a valid token that your API will accept. www.somerandomapi.com cannot get a token unless it has a client-secret (which it doesn't) or it's registered using the implicit flow and has registered a known redirect url with your IS4 instance (which, again, it hasn't).
    – Kirk Larkin
    Nov 19 at 21:59








  • 2




    @Bojan - just some clarification. IS4 in general doesn't know to protect your API. IS4 is issuing tokens (which can have your api name as a scope in them, if requested and allowed of course). Your API is validating these tokens, against IS4 (` options.Authority = "localhost:5000";` is the clue here). So if www.somerandomapi.com is a valid IS4 client, and is allowed access to your API scope, then it will receive a valid token from IS4 and will be able to access your API. But for www.somerandomapi.com to be a valid client, it should be registered in your IS4.
    – m3n7alsnak3
    Nov 20 at 21:05















up vote
0
down vote

favorite
1












I'm trying to use Identity Server 4 to protect my API. Now I have gone through all the documentation at http://docs.identityserver.io/en/release/quickstarts/1_client_credentials.html and I have set up a few successful demos. However, there is one thing that I am failing to understand.



For example, First, we need to define a client on the IS4 that looks like this:



new Client
{
ClientId = "client",

// no interactive user, use the clientid/secret for authentication
AllowedGrantTypes = GrantTypes.ClientCredentials,

// secret for authentication
ClientSecrets =
{
new Secret("secret".Sha256())
},

// scopes that client has access to
AllowedScopes = { "api1" }
}


Then on the API we protect it by adding the IdentityServer4.AccessTokenValidation package and adding configuration to startup.cs



services.AddMvcCore()
.AddAuthorization()
.AddJsonFormatters();

services.AddAuthentication("Bearer")
.AddIdentityServerAuthentication(options =>
{
options.Authority = "http://localhost:5000";
options.RequireHttpsMetadata = false;

options.ApiName = "api1";
});


And then finally we add app.UseAuthentication();



Now, this all works when ran, however, the part that I don't understand is where is the secret defined in the API. As you can see, the client clearly expects a secret and yet I don't define this secret anywhere on my API. I also don't define anywhere on the IS4 anything about my API to say that you are protecting the API from this URI or something along those lines.



So how does this actually works in terms of IS4 knowing about the API and authenticating its requests?



EDIT:



To clarify some confusion, yes there is a client that I opted out in code above and I see now that I shouldn't, and in there I provide a secret, but I'm still not understanding how does the IS4 knows to protect my specific API. What if the request came from www.somerandomapi.com? From what I"m reading it would work regardless. Based on what you wrote, it does make sense that the client is passing the secret, but nowhere in my code is the IS4 told which API to protect.










share|improve this question
























  • The secret is passed in from the client (docs.identityserver.io/en/release/quickstarts/…)
    – DavidG
    Nov 19 at 15:32






  • 2




    @CamiloTerevinto The client is passing in the secret though, that's how it get the bearer access token. The code works fine.
    – DavidG
    Nov 19 at 15:34








  • 2




    @CamiloTerevinto But that's how it works! The code above doesn't show the flow, just the setup. The question "where is the secret defined in the API" is meaningless - it's not defined there at all.
    – DavidG
    Nov 19 at 15:36








  • 1




    The API doesn't need a secret at all, as has been said. However, any client that wants to consume your API either needs a secret or a preregistered redirect url, for example, in order to get a valid token that your API will accept. www.somerandomapi.com cannot get a token unless it has a client-secret (which it doesn't) or it's registered using the implicit flow and has registered a known redirect url with your IS4 instance (which, again, it hasn't).
    – Kirk Larkin
    Nov 19 at 21:59








  • 2




    @Bojan - just some clarification. IS4 in general doesn't know to protect your API. IS4 is issuing tokens (which can have your api name as a scope in them, if requested and allowed of course). Your API is validating these tokens, against IS4 (` options.Authority = "localhost:5000";` is the clue here). So if www.somerandomapi.com is a valid IS4 client, and is allowed access to your API scope, then it will receive a valid token from IS4 and will be able to access your API. But for www.somerandomapi.com to be a valid client, it should be registered in your IS4.
    – m3n7alsnak3
    Nov 20 at 21:05













up vote
0
down vote

favorite
1









up vote
0
down vote

favorite
1






1





I'm trying to use Identity Server 4 to protect my API. Now I have gone through all the documentation at http://docs.identityserver.io/en/release/quickstarts/1_client_credentials.html and I have set up a few successful demos. However, there is one thing that I am failing to understand.



For example, First, we need to define a client on the IS4 that looks like this:



new Client
{
ClientId = "client",

// no interactive user, use the clientid/secret for authentication
AllowedGrantTypes = GrantTypes.ClientCredentials,

// secret for authentication
ClientSecrets =
{
new Secret("secret".Sha256())
},

// scopes that client has access to
AllowedScopes = { "api1" }
}


Then on the API we protect it by adding the IdentityServer4.AccessTokenValidation package and adding configuration to startup.cs



services.AddMvcCore()
.AddAuthorization()
.AddJsonFormatters();

services.AddAuthentication("Bearer")
.AddIdentityServerAuthentication(options =>
{
options.Authority = "http://localhost:5000";
options.RequireHttpsMetadata = false;

options.ApiName = "api1";
});


And then finally we add app.UseAuthentication();



Now, this all works when ran, however, the part that I don't understand is where is the secret defined in the API. As you can see, the client clearly expects a secret and yet I don't define this secret anywhere on my API. I also don't define anywhere on the IS4 anything about my API to say that you are protecting the API from this URI or something along those lines.



So how does this actually works in terms of IS4 knowing about the API and authenticating its requests?



EDIT:



To clarify some confusion, yes there is a client that I opted out in code above and I see now that I shouldn't, and in there I provide a secret, but I'm still not understanding how does the IS4 knows to protect my specific API. What if the request came from www.somerandomapi.com? From what I"m reading it would work regardless. Based on what you wrote, it does make sense that the client is passing the secret, but nowhere in my code is the IS4 told which API to protect.










share|improve this question















I'm trying to use Identity Server 4 to protect my API. Now I have gone through all the documentation at http://docs.identityserver.io/en/release/quickstarts/1_client_credentials.html and I have set up a few successful demos. However, there is one thing that I am failing to understand.



For example, First, we need to define a client on the IS4 that looks like this:



new Client
{
ClientId = "client",

// no interactive user, use the clientid/secret for authentication
AllowedGrantTypes = GrantTypes.ClientCredentials,

// secret for authentication
ClientSecrets =
{
new Secret("secret".Sha256())
},

// scopes that client has access to
AllowedScopes = { "api1" }
}


Then on the API we protect it by adding the IdentityServer4.AccessTokenValidation package and adding configuration to startup.cs



services.AddMvcCore()
.AddAuthorization()
.AddJsonFormatters();

services.AddAuthentication("Bearer")
.AddIdentityServerAuthentication(options =>
{
options.Authority = "http://localhost:5000";
options.RequireHttpsMetadata = false;

options.ApiName = "api1";
});


And then finally we add app.UseAuthentication();



Now, this all works when ran, however, the part that I don't understand is where is the secret defined in the API. As you can see, the client clearly expects a secret and yet I don't define this secret anywhere on my API. I also don't define anywhere on the IS4 anything about my API to say that you are protecting the API from this URI or something along those lines.



So how does this actually works in terms of IS4 knowing about the API and authenticating its requests?



EDIT:



To clarify some confusion, yes there is a client that I opted out in code above and I see now that I shouldn't, and in there I provide a secret, but I'm still not understanding how does the IS4 knows to protect my specific API. What if the request came from www.somerandomapi.com? From what I"m reading it would work regardless. Based on what you wrote, it does make sense that the client is passing the secret, but nowhere in my code is the IS4 told which API to protect.







c# api identityserver4






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 19 at 15:40

























asked Nov 19 at 15:28









Bojan

2,05992772




2,05992772












  • The secret is passed in from the client (docs.identityserver.io/en/release/quickstarts/…)
    – DavidG
    Nov 19 at 15:32






  • 2




    @CamiloTerevinto The client is passing in the secret though, that's how it get the bearer access token. The code works fine.
    – DavidG
    Nov 19 at 15:34








  • 2




    @CamiloTerevinto But that's how it works! The code above doesn't show the flow, just the setup. The question "where is the secret defined in the API" is meaningless - it's not defined there at all.
    – DavidG
    Nov 19 at 15:36








  • 1




    The API doesn't need a secret at all, as has been said. However, any client that wants to consume your API either needs a secret or a preregistered redirect url, for example, in order to get a valid token that your API will accept. www.somerandomapi.com cannot get a token unless it has a client-secret (which it doesn't) or it's registered using the implicit flow and has registered a known redirect url with your IS4 instance (which, again, it hasn't).
    – Kirk Larkin
    Nov 19 at 21:59








  • 2




    @Bojan - just some clarification. IS4 in general doesn't know to protect your API. IS4 is issuing tokens (which can have your api name as a scope in them, if requested and allowed of course). Your API is validating these tokens, against IS4 (` options.Authority = "localhost:5000";` is the clue here). So if www.somerandomapi.com is a valid IS4 client, and is allowed access to your API scope, then it will receive a valid token from IS4 and will be able to access your API. But for www.somerandomapi.com to be a valid client, it should be registered in your IS4.
    – m3n7alsnak3
    Nov 20 at 21:05


















  • The secret is passed in from the client (docs.identityserver.io/en/release/quickstarts/…)
    – DavidG
    Nov 19 at 15:32






  • 2




    @CamiloTerevinto The client is passing in the secret though, that's how it get the bearer access token. The code works fine.
    – DavidG
    Nov 19 at 15:34








  • 2




    @CamiloTerevinto But that's how it works! The code above doesn't show the flow, just the setup. The question "where is the secret defined in the API" is meaningless - it's not defined there at all.
    – DavidG
    Nov 19 at 15:36








  • 1




    The API doesn't need a secret at all, as has been said. However, any client that wants to consume your API either needs a secret or a preregistered redirect url, for example, in order to get a valid token that your API will accept. www.somerandomapi.com cannot get a token unless it has a client-secret (which it doesn't) or it's registered using the implicit flow and has registered a known redirect url with your IS4 instance (which, again, it hasn't).
    – Kirk Larkin
    Nov 19 at 21:59








  • 2




    @Bojan - just some clarification. IS4 in general doesn't know to protect your API. IS4 is issuing tokens (which can have your api name as a scope in them, if requested and allowed of course). Your API is validating these tokens, against IS4 (` options.Authority = "localhost:5000";` is the clue here). So if www.somerandomapi.com is a valid IS4 client, and is allowed access to your API scope, then it will receive a valid token from IS4 and will be able to access your API. But for www.somerandomapi.com to be a valid client, it should be registered in your IS4.
    – m3n7alsnak3
    Nov 20 at 21:05
















The secret is passed in from the client (docs.identityserver.io/en/release/quickstarts/…)
– DavidG
Nov 19 at 15:32




The secret is passed in from the client (docs.identityserver.io/en/release/quickstarts/…)
– DavidG
Nov 19 at 15:32




2




2




@CamiloTerevinto The client is passing in the secret though, that's how it get the bearer access token. The code works fine.
– DavidG
Nov 19 at 15:34






@CamiloTerevinto The client is passing in the secret though, that's how it get the bearer access token. The code works fine.
– DavidG
Nov 19 at 15:34






2




2




@CamiloTerevinto But that's how it works! The code above doesn't show the flow, just the setup. The question "where is the secret defined in the API" is meaningless - it's not defined there at all.
– DavidG
Nov 19 at 15:36






@CamiloTerevinto But that's how it works! The code above doesn't show the flow, just the setup. The question "where is the secret defined in the API" is meaningless - it's not defined there at all.
– DavidG
Nov 19 at 15:36






1




1




The API doesn't need a secret at all, as has been said. However, any client that wants to consume your API either needs a secret or a preregistered redirect url, for example, in order to get a valid token that your API will accept. www.somerandomapi.com cannot get a token unless it has a client-secret (which it doesn't) or it's registered using the implicit flow and has registered a known redirect url with your IS4 instance (which, again, it hasn't).
– Kirk Larkin
Nov 19 at 21:59






The API doesn't need a secret at all, as has been said. However, any client that wants to consume your API either needs a secret or a preregistered redirect url, for example, in order to get a valid token that your API will accept. www.somerandomapi.com cannot get a token unless it has a client-secret (which it doesn't) or it's registered using the implicit flow and has registered a known redirect url with your IS4 instance (which, again, it hasn't).
– Kirk Larkin
Nov 19 at 21:59






2




2




@Bojan - just some clarification. IS4 in general doesn't know to protect your API. IS4 is issuing tokens (which can have your api name as a scope in them, if requested and allowed of course). Your API is validating these tokens, against IS4 (` options.Authority = "localhost:5000";` is the clue here). So if www.somerandomapi.com is a valid IS4 client, and is allowed access to your API scope, then it will receive a valid token from IS4 and will be able to access your API. But for www.somerandomapi.com to be a valid client, it should be registered in your IS4.
– m3n7alsnak3
Nov 20 at 21:05




@Bojan - just some clarification. IS4 in general doesn't know to protect your API. IS4 is issuing tokens (which can have your api name as a scope in them, if requested and allowed of course). Your API is validating these tokens, against IS4 (` options.Authority = "localhost:5000";` is the clue here). So if www.somerandomapi.com is a valid IS4 client, and is allowed access to your API scope, then it will receive a valid token from IS4 and will be able to access your API. But for www.somerandomapi.com to be a valid client, it should be registered in your IS4.
– m3n7alsnak3
Nov 20 at 21:05

















active

oldest

votes











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',
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
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53377844%2fidentity-server-4-protect-an-api%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown






























active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































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.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • 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.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53377844%2fidentity-server-4-protect-an-api%23new-answer', 'question_page');
}
);

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







Popular posts from this blog

Create new schema in PostgreSQL using DBeaver

Deepest pit of an array with Javascript: test on Codility

Costa Masnaga