Web API Sample for Thinktecture.IdentityModel

2,808 views
Skip to first unread message

Dominick Baier

unread,
Jun 8, 2012, 1:13:59 PM6/8/12
to webapi...@googlegroups.com
I added a Web API sample for my authentication library. It shows:

- SAML
- SWT
- JWT
- Basic Authentication
- Access Key

feedback is welcome!

Alexander Zeitler

unread,
Jun 8, 2012, 7:37:03 PM6/8/12
to webapi...@googlegroups.com
Tested the Basic Auth - works nicely.

Had to change the following to get it running:

Compile the IdentityModel main project.

Commented out: 

<UseCustomServer>True</UseCustomServer>
<CustomServerUrl>https://adfs.leastprivilege.vm/webapisecurity</CustomServerUrl>

in the WebApiSecurity.csproj in the samples folder

Enabled IIS Express

In Constants.cs: 
changed WebHost to 
public const string WebHost = "localhost:1281/"; // 1281 is the IIS Express URL you get in the previous step

changed ServiceBaseAddressWebHost to 
public const string ServiceBaseAddressWebHost = "http://" + WebHost + "api/"; //remove https + change apis path

In case you're dealing with JavaScript clients + Basic Auth: how to you persist credentials on the client?

Alex

From: webapi...@googlegroups.com [webapi...@googlegroups.com] on behalf of Dominick Baier [dba...@gmail.com]
Sent: Friday, June 08, 2012 7:13 PM
To: webapi...@googlegroups.com
Subject: Web API Sample for Thinktecture.IdentityModel

--
You received this message because you are subscribed to the Google Groups "WebApiContrib" group.
To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/CDjmWPD6TJcJ.
To post to this group, send email to webapi...@googlegroups.com.
To unsubscribe from this group, send email to webapicontri...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/webapicontrib?hl=en.

Christian Weyer

unread,
Jun 9, 2012, 3:24:19 AM6/9/12
to webapi...@googlegroups.com

You don’t (in a fully secure way).

But here is an approach: http://www.codeproject.com/Articles/2600/JavaScript-password-protection-and-session-managem

Dominick Baier

unread,
Jun 9, 2012, 3:51:24 AM6/9/12
to webapi...@googlegroups.com
Thanks.

Storing a password has definitely become an anti pattern.

Rather use a password to request a token. Then throw away the password and store the token.

Tugberk Ugurlu

unread,
Jun 9, 2012, 3:59:36 AM6/9/12
to webapi...@googlegroups.com
Hi,

Thinktecture.IdentityModel is one of the coolest projects. Thank you guys
for putting the source code online.
In that case, assuming we would like to persist the authenticated connection
between the client and server, do u think that ASP.NET forms auth over HTTPS
with secure cookie option would be a secure choice?

-----Original Message-----
From: webapi...@googlegroups.com [mailto:webapi...@googlegroups.com]
--
You received this message because you are subscribed to the Google Groups
"WebApiContrib" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/webapicontrib/-/-NJa4bFu5jgJ.

Dominick Baier

unread,
Jun 9, 2012, 9:14:10 AM6/9/12
to webapi...@googlegroups.com
Yeah - don't like that ;)

Ultimately you don't want to store passwords on the local harddrive (or device).


On Saturday, June 9, 2012 9:24:19 AM UTC+2, Christian Weyer wrote:

You don’t (in a fully secure way).

But here is an approach: http://www.codeproject.com/Articles/2600/JavaScript-password-protection-and-session-managem

 

From: webapi...@googlegroups.com [mailto:webapicontrib@googlegroups.com] On Behalf Of Alexander Zeitler
Sent: Samstag, 9. Juni 2012 01:37
To: webapi...@googlegroups.com
Subject: RE: Web API Sample for Thinktecture.IdentityModel

 

Tested the Basic Auth - works nicely.

 

Had to change the following to get it running:

 

Compile the IdentityModel main project.

 

Commented out: 

 

<UseCustomServer>True</UseCustomServer>

 

in the WebApiSecurity.csproj in the samples folder

 

Enabled IIS Express

 

In Constants.cs: 

changed WebHost to 

public const string WebHost = "localhost:1281/"; // 1281 is the IIS Express URL you get in the previous step

 

changed ServiceBaseAddressWebHost to 

public const string ServiceBaseAddressWebHost = "http://" + WebHost + "api/"; //remove https + change apis path

 

In case you're dealing with JavaScript clients + Basic Auth: how to you persist credentials on the client?

 

Alex

From: webapi...@googlegroups.com [webapicontrib@googlegroups.com] on behalf of Dominick Baier
Sent: Friday, June 08, 2012 7:13 PM
To: webapi...@googlegroups.com
Subject: Web API Sample for Thinktecture.IdentityModel

I added a Web API sample for my authentication library. It shows:

 

- SAML

- SWT

- JWT

- Basic Authentication

- Access Key

 

feedback is welcome!

 

--
You received this message because you are subscribed to the Google Groups "WebApiContrib" group.
To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/CDjmWPD6TJcJ.
To post to this group, send email to webapi...@googlegroups.com.

To unsubscribe from this group, send email to webapicontrib+unsubscribe@googlegroups.com.


For more options, visit this group at http://groups.google.com/group/webapicontrib?hl=en.

--
You received this message because you are subscribed to the Google Groups "WebApiContrib" group.
To post to this group, send email to webapi...@googlegroups.com.

To unsubscribe from this group, send email to webapicontrib+unsubscribe@googlegroups.com.

Dominick Baier

unread,
Jun 9, 2012, 9:25:21 AM6/9/12
to webapi...@googlegroups.com
Thanks!

I have several concerns with the cookie approach. None of them are really security related though.

You are essentially creating a session and couple it with the transport. That goes clearly against the stateless "constraint" of http based services. But i'd rather be pragmatic - and if it works for you thats fine.

However - it makes the client considerably more complex. Session has to be established (that can be implicit). Sessions can time out or can get corrupted on the server. That session should (must) be web farm compatible. The client needs to be able to react to that.

I've been there with WCF SecurityConversation. And didn't like it (in fact our standard advice was to turn it off).

If i were to implement that, i'd rather use the WIF/.NET 4.5 session authentication mechanism over FormsAuth cookies. Much more powerful.

webapicontrib+unsubscribe@googlegroups.com.

Dominick Baier

unread,
Jun 9, 2012, 9:54:15 AM6/9/12
to webapi...@googlegroups.com
Then on the other hands - if you treat a cookie like an issued security token, where the issuer is embedded in the reyling party - AND follow the same semantics, i guess this approach is OK.

Thinking about it ;)

Alexander Zeitler

unread,
Jun 12, 2012, 8:48:52 AM6/12/12
to webapi...@googlegroups.com
Which header is used for the token in response/request?

Alex
________________________________________


From: webapi...@googlegroups.com [webapi...@googlegroups.com] on behalf of Dominick Baier [dba...@gmail.com]

Sent: Saturday, June 09, 2012 9:51 AM
To: webapi...@googlegroups.com
Subject: RE: Web API Sample for Thinktecture.IdentityModel

Thanks.

Storing a password has definitely become an anti pattern.

Rather use a password to request a token. Then throw away the password and store the token.

--


You received this message because you are subscribed to the Google Groups "WebApiContrib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/-NJa4bFu5jgJ.

Dominick Baier

unread,
Jun 12, 2012, 8:51:03 AM6/12/12
to webapi...@googlegroups.com
Well - typically the Authorization header. But I have seen a number of "alternatives" as well.


On Tuesday, June 12, 2012 2:48:52 PM UTC+2, Alexander Zeitler wrote:
Which header is used for the token in response/request?

Alex
________________________________________
From: webapi...@googlegroups.com [webapicontrib@googlegroups.com] on behalf of Dominick Baier 


Sent: Saturday, June 09, 2012 9:51 AM
To: webapi...@googlegroups.com
Subject: RE: Web API Sample for Thinktecture.IdentityModel

Thanks.

Storing a password has definitely become an anti pattern.

Rather use a password to request a token. Then throw away the password and store the token.

--
You received this message because you are subscribed to the Google Groups "WebApiContrib" group.
To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/-NJa4bFu5jgJ.
To post to this group, send email to webapi...@googlegroups.com.

To unsubscribe from this group, send email to webapicontrib+unsubscribe@googlegroups.com.

Alexander Zeitler

unread,
Jun 13, 2012, 3:40:29 PM6/13/12
to <webapicontrib@googlegroups.com>
Do you (plan to) support basic auth + token (in later requests)?

Alex


To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/5OmbedKv1lgJ.

To post to this group, send email to webapi...@googlegroups.com.
To unsubscribe from this group, send email to webapicontri...@googlegroups.com.

Dominick Baier

unread,
Jun 13, 2012, 4:20:30 PM6/13/12
to webapi...@googlegroups.com
I am considering it. But there are a number of different options here.

What exactly would you like to see, and which problem would it solve?

Dominick Baier

unread,
Jun 13, 2012, 4:20:33 PM6/13/12
to webapi...@googlegroups.com

Alexander Zeitler

unread,
Jun 13, 2012, 4:57:59 PM6/13/12
to webapi...@googlegroups.com
Main goal would be to not use the anti-pattern "storing credentials at the client after successful login".

Which options do you have in mind?

Alex
________________________________________
From: webapi...@googlegroups.com [webapi...@googlegroups.com] on behalf of Dominick Baier [dba...@gmail.com]
Sent: Wednesday, June 13, 2012 10:20 PM
To: webapi...@googlegroups.com
Subject: Re: Web API Sample for Thinktecture.IdentityModel

I am considering it. But there are a number of different options here.

What exactly would you like to see, and which problem would it solve?

--


You received this message because you are subscribed to the Google Groups "WebApiContrib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/lQPGSvdoUnkJ.

Dominick Baier

unread,
Jun 14, 2012, 2:30:55 AM6/14/12
to webapi...@googlegroups.com
Well - there is the cookie approach - i think i don't like that for web service communication.

I think the better approach would be a built-in token issuance endpoint, something like ~/issuetoken
or so.

This would return an OAuth2 response, containing a token and metadata (like the lifetime). From that point on the client could use that token for authentication.
Would that work for you?

Now - how long should that token live? Would you like to be able to renew the token?

On Wednesday, June 13, 2012 10:57:59 PM UTC+2, Alexander Zeitler wrote:
Main goal would be to not use the anti-pattern "storing credentials at the client after successful login".

Which options do you have in mind?

Alex
________________________________________
From: webapi...@googlegroups.com [webapicontrib@googlegroups.com] on behalf of Dominick Baier


Sent: Wednesday, June 13, 2012 10:20 PM
To: webapi...@googlegroups.com
Subject: Re: Web API Sample for Thinktecture.IdentityModel

I am considering it. But there are a number of different options here.

What exactly would you like to see, and which problem would it solve?

--
You received this message because you are subscribed to the Google Groups "WebApiContrib" group.
To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/lQPGSvdoUnkJ.
To post to this group, send email to webapi...@googlegroups.com.

To unsubscribe from this group, send email to webapicontrib+unsubscribe@googlegroups.com.

Alexander Zeitler

unread,
Jun 14, 2012, 5:04:13 AM6/14/12
to webapi...@googlegroups.com
The token lifetime should be configurable. Renewing the token should be possible.

Thanks

Alex
From: webapi...@googlegroups.com [webapi...@googlegroups.com] on behalf of Dominick Baier [dba...@gmail.com]
Sent: Thursday, June 14, 2012 8:30 AM
To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/5OSdmJ9yH88J.

To post to this group, send email to webapi...@googlegroups.com.
To unsubscribe from this group, send email to webapicontri...@googlegroups.com.

Dominick Baier

unread,
Jun 14, 2012, 5:09:10 AM6/14/12
to webapi...@googlegroups.com
;) and that's where I becomes hard from security point of view (not technically).

When the token is renewable, this basically means that whoever has a token can keep it alive forever. And without introducing a full fledged clientId/secret management system, there is no way for a user to revoke access to his identity.

I think a good compromise is what e.g. Google or LiveID do - they issue a long lived token (e.g. 2 weeks), but after that the user has to re-authenticate.

Thoughts?


On Thursday, June 14, 2012 11:04:13 AM UTC+2, Alexander Zeitler wrote:
The token lifetime should be configurable. Renewing the token should be possible.

Thanks

Alex

Alexander Zeitler

unread,
Jun 14, 2012, 5:12:54 AM6/14/12
to webapi...@googlegroups.com
That compromise should work.

Alex
From: webapi...@googlegroups.com [webapi...@googlegroups.com] on behalf of Dominick Baier [dba...@gmail.com]
Sent: Thursday, June 14, 2012 11:09 AM
To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/8v20rUMCRkAJ.

To post to this group, send email to webapi...@googlegroups.com.
To unsubscribe from this group, send email to webapicontri...@googlegroups.com.

Dominick Baier

unread,
Jun 15, 2012, 5:24:01 PM6/15/12
to webapi...@googlegroups.com
ok. yeah will work on it.


On Thursday, June 14, 2012 11:12:54 AM UTC+2, Alexander Zeitler wrote:
That compromise should work.

Alex

Alexander Zeitler

unread,
Jun 15, 2012, 5:57:36 PM6/15/12
to <webapicontrib@googlegroups.com>
Great!

Thanks,

Alex


To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/Qduyo70EuiIJ.

To post to this group, send email to webapi...@googlegroups.com.
To unsubscribe from this group, send email to webapicontri...@googlegroups.com.

Alexander Zeitler

unread,
Aug 15, 2012, 4:53:03 PM8/15/12
to webapi...@googlegroups.com
What's the current state on the token story?

Alex


Am Freitag, 15. Juni 2012 23:24:01 UTC+2 schrieb Dominick Baier:
ok. yeah will work on it.

On Thursday, June 14, 2012 11:12:54 AM UTC+2, Alexander Zeitler wrote:
That compromise should work.

Alex
From: webapi...@googlegroups.com [webapi...@googlegroups.com] on behalf of Dominick Baier

Sent: Thursday, June 14, 2012 11:09 AM
To: webapi...@googlegroups.com
Subject: Re: Web API Sample for Thinktecture.IdentityModel
;) and that's where I becomes hard from security point of view (not technically).

When the token is renewable, this basically means that whoever has a token can keep it alive forever. And without introducing a full fledged clientId/secret management system, there is no way for a user to revoke access to his identity.

I think a good compromise is what e.g. Google or LiveID do - they issue a long lived token (e.g. 2 weeks), but after that the user has to re-authenticate.

Thoughts?

On Thursday, June 14, 2012 11:04:13 AM UTC+2, Alexander Zeitler wrote:
The token lifetime should be configurable. Renewing the token should be possible.

Thanks

Alex
From: webapi...@googlegroups.com [webapi...@googlegroups.com] on behalf of Dominick Baier

Sent: Thursday, June 14, 2012 8:30 AM
To: webapi...@googlegroups.com
Subject: Re: Web API Sample for Thinktecture.IdentityModel
Well - there is the cookie approach - i think i don't like that for web service communication.

I think the better approach would be a built-in token issuance endpoint, something like ~/issuetoken
or so.

This would return an OAuth2 response, containing a token and metadata (like the lifetime). From that point on the client could use that token for authentication.
Would that work for you?

Now - how long should that token live? Would you like to be able to renew the token?

On Wednesday, June 13, 2012 10:57:59 PM UTC+2, Alexander Zeitler wrote:
Main goal would be to not use the anti-pattern "storing credentials at the client after successful login".

Which options do you have in mind?

Alex
________________________________________
From: webapi...@googlegroups.com [webapi...@googlegroups.com] on behalf of Dominick Baier


Sent: Wednesday, June 13, 2012 10:20 PM
To: webapi...@googlegroups.com
Subject: Re: Web API Sample for Thinktecture.IdentityModel

I am considering it. But there are a number of different options here.

What exactly would you like to see, and which problem would it solve?

--
You received this message because you are subscribed to the Google Groups "WebApiContrib" group.
To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/lQPGSvdoUnkJ.
To post to this group, send email to webapi...@googlegroups.com.

To unsubscribe from this group, send email to webapicontri...@googlegroups.com.


For more options, visit this group at http://groups.google.com/group/webapicontrib?hl=en.

--
You received this message because you are subscribed to the Google Groups "WebApiContrib" group.
To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/5OSdmJ9yH88J.
To post to this group, send email to webapi...@googlegroups.com.
To unsubscribe from this group, send email to webapicontri...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/webapicontrib?hl=en.

--
You received this message because you are subscribed to the Google Groups "WebApiContrib" group.
To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/8v20rUMCRkAJ.
To post to this group, send email to webapi...@googlegroups.com.
To unsubscribe from this group, send email to webapicontri...@googlegroups.com.

Dominick Baier

unread,
Aug 16, 2012, 6:24:34 AM8/16/12
to webapi...@googlegroups.com
Alive and kicking ;)

Well - the code is written, there is also a sample in the repo. Lemme know if it works for you.

Alexander Zeitler

unread,
Aug 16, 2012, 7:21:58 AM8/16/12
to webapi...@googlegroups.com
What's the workflow now to get the token and use it?
Is Thinktecture.IdentityModel.45 the project to go?
Is the NuGet package up to date?

From: webapi...@googlegroups.com [webapi...@googlegroups.com] on behalf of Dominick Baier [dba...@gmail.com]
Sent: Thursday, August 16, 2012 12:24 PM
To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/xUpZKDGrzbAJ.

Dominick Baier

unread,
Aug 16, 2012, 7:25:28 AM8/16/12
to webapi...@googlegroups.com
See the repo samples - that's the easiest. I also wrote a blog post about it.

both 4.5 and 4.0 are current - the nugets as well.

Alexander Zeitler

unread,
Aug 16, 2012, 7:41:58 AM8/16/12
to webapi...@googlegroups.com
Thx, I missed the the JavaScriptClients project.
In the current version there seems to be an issue with JSONP calls.
When copying the JS client stuff to the WebHost prj, everything works as expected.

Sent: Thursday, August 16, 2012 1:25 PM
To view this discussion on the web visit https://groups.google.com/d/msg/webapicontrib/-/QsgVFq4_JacJ.

Christian Weyer

unread,
Aug 16, 2012, 11:43:29 AM8/16/12
to webapi...@googlegroups.com

Or same origin…

Alexander Zeitler

unread,
Aug 16, 2012, 11:49:53 AM8/16/12
to webapi...@googlegroups.com

Yes, as said, it works on same origin but not cross domain.

Christian Weyer

unread,
Aug 16, 2012, 11:55:22 AM8/16/12
to webapi...@googlegroups.com

You said it works when copied to the WebHost project. But it also works if the “client” web is on the same server/port.

Alexander Zeitler

unread,
Aug 16, 2012, 11:57:26 AM8/16/12
to webapi...@googlegroups.com

Yes, but that’s not my scenario ;-)

Alexander Zeitler

unread,
Aug 16, 2012, 11:58:35 AM8/16/12
to webapi...@googlegroups.com

The feedback was meant this way: you may update the sample accordingly as others might face this problem also ;-)

Alexander Zeitler

unread,
Aug 16, 2012, 12:59:23 PM8/16/12
to webapi...@googlegroups.com

Another issue:

I installed Thinkecture.IdentyModel.45 via NuGet, configured Basic Auth and ran it using Fiddler:

{"message":"No HTTP resource was found that matches the request URI 'http://localhost:49957/api/token?_=1345134035795'.","messageDetail":"No type was found that matches the controller named 'token'."}

 

Then I kicked the NuGet package out of the sln, referenced the Thinktecture.IdentyModel.45 project being cloned from latest GitHub source and ran it again:

Voilà – me can has token ;-)

Christian Weyer

unread,
Aug 17, 2012, 3:28:56 AM8/17/12
to webapi...@googlegroups.com

Yes, I saw something similar with the 4.0 0package the other day. Will need to investigate (after vacation J)

Dominick Baier

unread,
Sep 10, 2012, 3:21:45 AM9/10/12
to webapi...@googlegroups.com
I updated the Nuget. If you want to give it a try...

I will also change the semantics of the expire_in response field at some point. This is a bug. 
Reply all
Reply to author
Forward
0 new messages