Azure AD Auth with Angular and .NETCore2 WEBAPI
I want to add authentication to my app using Azure AD
Right now my flow is like
User -> AngularApp -> Azure Login -> AngularApp w/token -> API Call to backend w/token -> API Backend verifies token with Azure each call
I have following questions:
- Is there a better way to do this?
- Every API call is verified with azure. Is is required?
- Should i have two different client id for UI and API?
angular asp.net-web-api azure-active-directory asp.net-core-2.1
add a comment |
I want to add authentication to my app using Azure AD
Right now my flow is like
User -> AngularApp -> Azure Login -> AngularApp w/token -> API Call to backend w/token -> API Backend verifies token with Azure each call
I have following questions:
- Is there a better way to do this?
- Every API call is verified with azure. Is is required?
- Should i have two different client id for UI and API?
angular asp.net-web-api azure-active-directory asp.net-core-2.1
add a comment |
I want to add authentication to my app using Azure AD
Right now my flow is like
User -> AngularApp -> Azure Login -> AngularApp w/token -> API Call to backend w/token -> API Backend verifies token with Azure each call
I have following questions:
- Is there a better way to do this?
- Every API call is verified with azure. Is is required?
- Should i have two different client id for UI and API?
angular asp.net-web-api azure-active-directory asp.net-core-2.1
I want to add authentication to my app using Azure AD
Right now my flow is like
User -> AngularApp -> Azure Login -> AngularApp w/token -> API Call to backend w/token -> API Backend verifies token with Azure each call
I have following questions:
- Is there a better way to do this?
- Every API call is verified with azure. Is is required?
- Should i have two different client id for UI and API?
angular asp.net-web-api azure-active-directory asp.net-core-2.1
angular asp.net-web-api azure-active-directory asp.net-core-2.1
asked Nov 27 '18 at 6:27
Ankit RaonkaAnkit Raonka
1,41341434
1,41341434
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Is there a better way to do this?
This is the standard way.
Every API call is verified with azure. Is is required?
Your API back-end does not verify the token with AAD each time.
It downloads the public signing keys for Azure AD at startup (if you use standard components), and verifies the token using them.
Should i have two different client id for UI and API?
When you make a v2 application through the new App registrations experience, you can define the front-end and back-end API in a single app quite nicely.
You can also define them as separate apps.
add a comment |
What do you mean better? (less redirects?)
What you describe is a standard OpenID Connect flow that is used all over web right now. Whenever you are using your google, facebook, github login to log to some other page you are using that standard.
It is pretty secure and easy way of doing authorization/authentication on the web these days.
A little side note make sure that the token is valid for appropriate amount of time.
by better i mean, any better approach, yeah maybe less redirects also. Is it fine to call azure each time? Also if i follow this approach should i keep two seperate clientIds or same clientId for both ui and api?
– Ankit Raonka
Nov 27 '18 at 7:27
2
There is no way to do less redirects. The spec is very specific on how to exchange credential for a token. As for token verification by Azure it is an interesting one. As the answer is no, once you have the token all the information you need to verify that it's valid are encoded in the token. What is your backend? Something in java by any chance?
– piotr szybicki
Nov 27 '18 at 7:49
only communication with the Aure should be to get the certificate used to sign the token.
– piotr szybicki
Nov 27 '18 at 7:51
Thanks Backend is in .netCore
– Ankit Raonka
Nov 27 '18 at 9:07
then i can't help you with the details. But would take a closer look at how the token is validated by your services. If you have a separate library that does that for you, maybe the problem is there.
– piotr szybicki
Nov 27 '18 at 9:16
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%2f53493931%2fazure-ad-auth-with-angular-and-netcore2-webapi%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
Is there a better way to do this?
This is the standard way.
Every API call is verified with azure. Is is required?
Your API back-end does not verify the token with AAD each time.
It downloads the public signing keys for Azure AD at startup (if you use standard components), and verifies the token using them.
Should i have two different client id for UI and API?
When you make a v2 application through the new App registrations experience, you can define the front-end and back-end API in a single app quite nicely.
You can also define them as separate apps.
add a comment |
Is there a better way to do this?
This is the standard way.
Every API call is verified with azure. Is is required?
Your API back-end does not verify the token with AAD each time.
It downloads the public signing keys for Azure AD at startup (if you use standard components), and verifies the token using them.
Should i have two different client id for UI and API?
When you make a v2 application through the new App registrations experience, you can define the front-end and back-end API in a single app quite nicely.
You can also define them as separate apps.
add a comment |
Is there a better way to do this?
This is the standard way.
Every API call is verified with azure. Is is required?
Your API back-end does not verify the token with AAD each time.
It downloads the public signing keys for Azure AD at startup (if you use standard components), and verifies the token using them.
Should i have two different client id for UI and API?
When you make a v2 application through the new App registrations experience, you can define the front-end and back-end API in a single app quite nicely.
You can also define them as separate apps.
Is there a better way to do this?
This is the standard way.
Every API call is verified with azure. Is is required?
Your API back-end does not verify the token with AAD each time.
It downloads the public signing keys for Azure AD at startup (if you use standard components), and verifies the token using them.
Should i have two different client id for UI and API?
When you make a v2 application through the new App registrations experience, you can define the front-end and back-end API in a single app quite nicely.
You can also define them as separate apps.
answered Nov 27 '18 at 7:48
juunasjuunas
22.5k34880
22.5k34880
add a comment |
add a comment |
What do you mean better? (less redirects?)
What you describe is a standard OpenID Connect flow that is used all over web right now. Whenever you are using your google, facebook, github login to log to some other page you are using that standard.
It is pretty secure and easy way of doing authorization/authentication on the web these days.
A little side note make sure that the token is valid for appropriate amount of time.
by better i mean, any better approach, yeah maybe less redirects also. Is it fine to call azure each time? Also if i follow this approach should i keep two seperate clientIds or same clientId for both ui and api?
– Ankit Raonka
Nov 27 '18 at 7:27
2
There is no way to do less redirects. The spec is very specific on how to exchange credential for a token. As for token verification by Azure it is an interesting one. As the answer is no, once you have the token all the information you need to verify that it's valid are encoded in the token. What is your backend? Something in java by any chance?
– piotr szybicki
Nov 27 '18 at 7:49
only communication with the Aure should be to get the certificate used to sign the token.
– piotr szybicki
Nov 27 '18 at 7:51
Thanks Backend is in .netCore
– Ankit Raonka
Nov 27 '18 at 9:07
then i can't help you with the details. But would take a closer look at how the token is validated by your services. If you have a separate library that does that for you, maybe the problem is there.
– piotr szybicki
Nov 27 '18 at 9:16
add a comment |
What do you mean better? (less redirects?)
What you describe is a standard OpenID Connect flow that is used all over web right now. Whenever you are using your google, facebook, github login to log to some other page you are using that standard.
It is pretty secure and easy way of doing authorization/authentication on the web these days.
A little side note make sure that the token is valid for appropriate amount of time.
by better i mean, any better approach, yeah maybe less redirects also. Is it fine to call azure each time? Also if i follow this approach should i keep two seperate clientIds or same clientId for both ui and api?
– Ankit Raonka
Nov 27 '18 at 7:27
2
There is no way to do less redirects. The spec is very specific on how to exchange credential for a token. As for token verification by Azure it is an interesting one. As the answer is no, once you have the token all the information you need to verify that it's valid are encoded in the token. What is your backend? Something in java by any chance?
– piotr szybicki
Nov 27 '18 at 7:49
only communication with the Aure should be to get the certificate used to sign the token.
– piotr szybicki
Nov 27 '18 at 7:51
Thanks Backend is in .netCore
– Ankit Raonka
Nov 27 '18 at 9:07
then i can't help you with the details. But would take a closer look at how the token is validated by your services. If you have a separate library that does that for you, maybe the problem is there.
– piotr szybicki
Nov 27 '18 at 9:16
add a comment |
What do you mean better? (less redirects?)
What you describe is a standard OpenID Connect flow that is used all over web right now. Whenever you are using your google, facebook, github login to log to some other page you are using that standard.
It is pretty secure and easy way of doing authorization/authentication on the web these days.
A little side note make sure that the token is valid for appropriate amount of time.
What do you mean better? (less redirects?)
What you describe is a standard OpenID Connect flow that is used all over web right now. Whenever you are using your google, facebook, github login to log to some other page you are using that standard.
It is pretty secure and easy way of doing authorization/authentication on the web these days.
A little side note make sure that the token is valid for appropriate amount of time.
answered Nov 27 '18 at 6:44
piotr szybickipiotr szybicki
6511510
6511510
by better i mean, any better approach, yeah maybe less redirects also. Is it fine to call azure each time? Also if i follow this approach should i keep two seperate clientIds or same clientId for both ui and api?
– Ankit Raonka
Nov 27 '18 at 7:27
2
There is no way to do less redirects. The spec is very specific on how to exchange credential for a token. As for token verification by Azure it is an interesting one. As the answer is no, once you have the token all the information you need to verify that it's valid are encoded in the token. What is your backend? Something in java by any chance?
– piotr szybicki
Nov 27 '18 at 7:49
only communication with the Aure should be to get the certificate used to sign the token.
– piotr szybicki
Nov 27 '18 at 7:51
Thanks Backend is in .netCore
– Ankit Raonka
Nov 27 '18 at 9:07
then i can't help you with the details. But would take a closer look at how the token is validated by your services. If you have a separate library that does that for you, maybe the problem is there.
– piotr szybicki
Nov 27 '18 at 9:16
add a comment |
by better i mean, any better approach, yeah maybe less redirects also. Is it fine to call azure each time? Also if i follow this approach should i keep two seperate clientIds or same clientId for both ui and api?
– Ankit Raonka
Nov 27 '18 at 7:27
2
There is no way to do less redirects. The spec is very specific on how to exchange credential for a token. As for token verification by Azure it is an interesting one. As the answer is no, once you have the token all the information you need to verify that it's valid are encoded in the token. What is your backend? Something in java by any chance?
– piotr szybicki
Nov 27 '18 at 7:49
only communication with the Aure should be to get the certificate used to sign the token.
– piotr szybicki
Nov 27 '18 at 7:51
Thanks Backend is in .netCore
– Ankit Raonka
Nov 27 '18 at 9:07
then i can't help you with the details. But would take a closer look at how the token is validated by your services. If you have a separate library that does that for you, maybe the problem is there.
– piotr szybicki
Nov 27 '18 at 9:16
by better i mean, any better approach, yeah maybe less redirects also. Is it fine to call azure each time? Also if i follow this approach should i keep two seperate clientIds or same clientId for both ui and api?
– Ankit Raonka
Nov 27 '18 at 7:27
by better i mean, any better approach, yeah maybe less redirects also. Is it fine to call azure each time? Also if i follow this approach should i keep two seperate clientIds or same clientId for both ui and api?
– Ankit Raonka
Nov 27 '18 at 7:27
2
2
There is no way to do less redirects. The spec is very specific on how to exchange credential for a token. As for token verification by Azure it is an interesting one. As the answer is no, once you have the token all the information you need to verify that it's valid are encoded in the token. What is your backend? Something in java by any chance?
– piotr szybicki
Nov 27 '18 at 7:49
There is no way to do less redirects. The spec is very specific on how to exchange credential for a token. As for token verification by Azure it is an interesting one. As the answer is no, once you have the token all the information you need to verify that it's valid are encoded in the token. What is your backend? Something in java by any chance?
– piotr szybicki
Nov 27 '18 at 7:49
only communication with the Aure should be to get the certificate used to sign the token.
– piotr szybicki
Nov 27 '18 at 7:51
only communication with the Aure should be to get the certificate used to sign the token.
– piotr szybicki
Nov 27 '18 at 7:51
Thanks Backend is in .netCore
– Ankit Raonka
Nov 27 '18 at 9:07
Thanks Backend is in .netCore
– Ankit Raonka
Nov 27 '18 at 9:07
then i can't help you with the details. But would take a closer look at how the token is validated by your services. If you have a separate library that does that for you, maybe the problem is there.
– piotr szybicki
Nov 27 '18 at 9:16
then i can't help you with the details. But would take a closer look at how the token is validated by your services. If you have a separate library that does that for you, maybe the problem is there.
– piotr szybicki
Nov 27 '18 at 9:16
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%2f53493931%2fazure-ad-auth-with-angular-and-netcore2-webapi%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