Secure API - Best place to put the username/password?


  • Trolleybus Mechanic

     I'm going to have to secure a public API. Since I've never done it before, I would very much like to avoid having the solution appear on the front page. So what's the best way to do so?

    The connection will be SSL. That's a given.

    The two methods on the table at the moment are:

    1) The API call takes three params: UserName, Password, and XMLData.  The XMLData will also contain a GUID/token of some sorts.

    2) The API only takes one param: XMLData. The XMLData will contain two additional fields, <username /> and <password />

    #2 is the one the other team is pitching, but something feels off about it to me. I can't quite place my finger on it. I think it's because it requires parsing "unauthenticated" data-- and also because the incoming XML will have to be modified to strip out username and password before the raw XML gets saved anywhere (logs, database for auditing purposes, etc).

    Any advice from the WTF community at large?


  • ♿ (Parody)

    @Lorne Kates said:

    #2 is the one the other team is pitching, but something feels off about it to me.

    It feels off because it is off. Actually, it's more than off, it's just stupid.

    This is yet another case of developers not understanding how SSL works. Which is not surprising, because it's the simplest fucking thing to understand: Secure Socket Layer. This means the entire Socket Layer is Secure.

    • IP
    • TCP
    • SSL
    • HTTP
    • SOAP
    • API

    Since the layer below HTTP is secured, that means HTTP and everything on top of it is also secured. There's no need to "encrypt" querystrings. Or POST data. Or anything else. It's already encrypted.


  • Discourse touched me in a no-no place

    Is this like a web-service used by 3rd party programs that would be amenable to using HMAC? Or is it simply an interface users simply log into?



    i.e. (to use Google as an example) is it someone simply logging into GMail with username/password to read their spam, or some application using the Google Maps API to show where their basement is?


  • ♿ (Parody)

    @PJH said:

    HMAC

    Jesus Fucking Christ.

    Thank you for finding a perfect example of a fuckwhit developer who doesn't understand how SSL works and therefore invents a stupid as shit* solution that is probably less secure.

    * to be fair, I barely skimmed the article, so it could be stupid as fuck; I'm giving the author a benefit of the doubt by assuming he's only completely incompetent, not mentally retarded


  • Trolleybus Mechanic

    @PJH said:

    Is this like a web-service used by 3rd party programs that would be amenable to using HMAC?
     

    I like it.

    The basic overview is our system is sending user data to another system. We're doing intake, they're doing donw-the-line services. That system also sends updates to our system.

    1) User registers on our system, completes a form.

    2) Our system sends all the user registration data to their system via [To Be Determined]

    3) Their system creates a Their System User Record

    4) Their system modifies that user record. People do manually checks. Someone finally authorizes the account, and it becomes active on their system.

    5) Their system sends us a update request to let our system know the user has been accepted/rejected, and what their new client # is.

    So it isn't really a public API per-se, but it'll be sitting on the wide-open Internet. So it might as well be.


  • Trolleybus Mechanic

    @Alex Papadimoulis said:

    Thank you for finding a perfect example of a fuckwhit developer who doesn't understand how SSL works and therefore invents a stupid as shit* solution that is probably less secure.
     

    I assumed HMAC was using SSL in addition to what they describe. It has to be SSL. If for some reason it shouldn't be-- then that reason is stupid. It has to be.

    Basic jist of article is:

    1) Get two keys from server, one public, one private

    2) Create your message to server. Sign it with your private key. Send your public key.  ("Key" is really just a user id)

    3) Server gets message with your XML, your user ID, and a hashsignature

    4) Using your user id, it pulls up your "private" key from DB and uses it to check the hash-signature of the message

    5) If they match, that's the same as having provided a username and password. Message is "good" and is processed.

    There's some cruft in there about timestamping and George Bush. It's basically message signing with PKE lite.


  • Discourse touched me in a no-no place

    @Alex Papadimoulis said:

    @PJH said:

    HMAC

    Jesus Fucking Christ.

    Thank you for finding a perfect example of a fuckwhit developer who doesn't understand how SSL works and therefore invents a stupid as shit* solution that is probably less secure.

    Yer welcome. That said, there is an update towards the end:

    Update #1: There are some fantastic feedback and ideas on securing a web-API down in the comments, I would highly recommend reading them.

    Some highlights are:

    [...]
    Remove all the security complexity by sending all traffic to go over SSL (HTTPS)!
    I was rather linking to the article as a basic primer for HMAC, since I was assuming Lorne was unfamiliar with the concept, with a view to presuming they would use it to better train their Google-fu for further queries, rather than using it like a student would use a Wikipedia article (only) on which to base their thesis and simply copy-paste the article into their application if it (the idea, not the code) seemed remotely suitable for their project.

  • ♿ (Parody)

    @PJH said:

    Yer welcome. That said, there is an update towards the end:
    Update #1: There are some fantastic feedback and ideas on securing a web-API down in the comments, I would highly recommend reading them.
    Some highlights are:

    [...]
    Remove all the security complexity by sending all traffic to go over SSL (HTTPS)!

    Hahahaha.

    Ok, I'll give him some credit then... at least he's not being stubborn about it. I've seen devs dig themselves deeper by talking about SSL "can be cracked" if you have access to the web server receiving the request. As if that's the least of your problems when you give up control of the server that's receiving your API requests.

    I'd give him more credit if he posted "You could use SSL, or... [entire article body]".



  • @Lorne Kates said:

     I'm going to have to secure a public API. Since I've never done it before, I would very much like to avoid having the solution appear on the front page. So what's the best way to do so?

    The connection will be SSL. That's a given.

    The two methods on the table at the moment are:

    1) The API call takes three params: UserName, Password, and XMLData.  The XMLData will also contain a GUID/token of some sorts.

    2) The API only takes one param: XMLData. The XMLData will contain two additional fields, <username /> and <password />

    #2 is the one the other team is pitching, but something feels off about it to me. I can't quite place my finger on it. I think it's because it requires parsing "unauthenticated" data-- and also because the incoming XML will have to be modified to strip out username and password before the raw XML gets saved anywhere (logs, database for auditing purposes, etc).

    Any advice from the WTF community at large?

    Generally, I've done a version of option #1. The user sends a username and password login request and gets back a session token if authenticated. The session token can then be used for all API calls in the header of the SOAP request. The token expires after some period of non-use, forcing re-authentication. Depending on what technology you are using, this is pretty trivial to implement.

    I'm, personally, not a fan of mixing data with credentials, but as long as you're using some sort of xslt to strip the username/password before saving it for audits, etc. that's still trivial to implement.


  • Trolleybus Mechanic

    @Alex Papadimoulis said:

    I'd give him more credit if he posted "You could use SSL, or... [entire article body]".
     

    Thing is, I know SSL will encrypt the entire message. Eavesdropping is taken care of.  My concern at this point is how to authenticate the message.  How do I ensure that only my system (or any other authorized systems in the future) send "Yo, here's a new client record!" requests.  I need to identify the entity sending the request, and authenticate that they have permission.

    If this were a standard website, I'd throw a Username and Password textbox on a SSL page and it's done.


  • ♿ (Parody)

    @Lorne Kates said:

    I assumed HMAC was using SSL in addition to what they describe

    Of course it isn't. If the author understood SSL then he would have never written this article. Or maybe he would have, and then added "just make sure to ROT-13 your strings as well, just to be extra secure".


  • ♿ (Parody)

    @Lorne Kates said:

    My concern at this point is how to authenticate the message. 

    Just use an API Key (long nonsensical string) or a name/password (a string plus a long nonsensical string).


  • Trolleybus Mechanic

    @Alex Papadimoulis said:

    @Lorne Kates said:

    My concern at this point is how to authenticate the message. 

    Just use an API Key (long nonsensical string) or a name/password (a string plus a long nonsensical string).

     

    Would you reccomend having that in the XML request itself (ie: what they want to do-- modify every XML schema we've come up with sofar to include <identifyingCrap />), or build it into the SOAP request itself... [code]DoShit(string IdentifyingCrap, string xmlData)[/code]

    Again my main concern is that since I'm a rookie at designing an API, I would like to minimize the rookie mistakes. =)

     


  • ♿ (Parody)

    Keep separate things separate. Authentication and Usage are separate, and should be as separated as possible. This simplifies everything for everyone -- consumers and producers. This is why SSL is at a layer below HTTP. Consumers/Producers of HTTP don't need to worry about it.

    If you're using SOAP, you should check out the built-in authentication header stuff. No idea how it works (it may not), but that's what it was designed for.

    If not, just go with #1 (name/pass as a param) or use an api key (single param). They're effectively the exact same thing from a security/usage point... but if API Keys are an actual requirement (i.e. users want to generate them from their account and give to their developers, or whatever), then go with that.

    Otherwise, make sure to abstract each and every API method like:

    public DoShit(authCrap, data) { VerifyAuth(authCrap); DoShitNoAuth(data); }
    private DoShitNoAuth(data) { ... }

    Or somethign like that. That makes sure you don't accidently code a dependency on authCrap when you doShit.



  • Here's how I've done it (disclaimer: I haven't read the other posts).

    My API has a call that specifically does authentication-- the caller uses it, passes in their user/pass (over SSL of course), the API checks this and returns to them a token. The token consists if: the user's username, password, the max date they're authenticated *until* (an hour, unless they checked "keep me logged in", in which case it's 2 weeks), and some other basic info (for example, what client they belong to, whether they're an administrator for that client.) It also attempts to set a cookie containing the token, so if you're using it from a web browser sending the token is "optional". This token is padded (fore and aft) with some random characters (just in case), then encrypted using the Rijndael AES standard, then Base-64 encoded.

    The advantage of this is that your token is now "portable", in that any web server you talk to can trust you're you without re-authenticating. Since our app scales horizontally, and there's no session storage, this is really important to us. If you're talking to us from a browser on the same domain, you can ignore the token, since the cookie will automatically take care of that for you, so this really simplifies implementation in the most common case. Or, if you're on a different domain, you just pass the token along and you get a new one returned that's identical except the "until" date is incremented by an hour since you made the request. (Cross-domain requests can be done with either the JSONP or CORS standards.)

    We can also manually hand out "keep me logged in" 2-week tokens if needed for a developer who doesn't have a user/pass on the system, so he can work with the API.

    I'm sure at least part of this process is WTF-y. Please let me know.



  • @blakeyrat said:

    Here's how I've done it (disclaimer: I haven't read the other posts).

    My API has a call that specifically does authentication-- the caller uses it, passes in their user/pass (over SSL of course), the API checks this and returns to them a token. The token consists if: the user's username, password, the max date they're authenticated *until* (an hour, unless they checked "keep me logged in", in which case it's 2 weeks), and some other basic info (for example, what client they belong to, whether they're an administrator for that client.) It also attempts to set a cookie containing the token, so if you're using it from a web browser sending the token is "optional". This token is padded (fore and aft) with some random characters (just in case), then encrypted using the Rijndael AES standard, then Base-64 encoded.

    The advantage of this is that your token is now "portable", in that any web server you talk to can trust you're you without re-authenticating. Since our app scales horizontally, and there's no session storage, this is really important to us. If you're talking to us from a browser on the same domain, you can ignore the token, since the cookie will automatically take care of that for you, so this really simplifies implementation in the most common case. Or, if you're on a different domain, you just pass the token along and you get a new one returned that's identical except the "until" date is incremented by an hour since you made the request. (Cross-domain requests can be done with either the JSONP or CORS standards.)

    We can also manually hand out "keep me logged in" 2-week tokens if needed for a developer who doesn't have a user/pass on the system, so he can work with the API.

    I'm sure at least part of this process is WTF-y. Please let me know.

     

    That's pretty similar to how the systems I've developed handle authentication. Of course it's still all done over SSL since the first login step must send a password, and all additional work is done over SSL to prevent eavesdropping and theft of valid and active tokens. Plus this isn't 1995 anymore and SSL has very little performance overhead. If you've got the cert, might as well use it for everything.

    I generate tokens using new GUIDs and then performing an SHA hash on them. The client website also sends AJAX keepalive requests to tell the server "Hey, this token is still active!" And if a keepalive isn't received within ten minutes, the server assumes the client is gone and deletes the token. The token is no longer valid and will not be accepted by the web API. Logouts also result in the deletion of the client's token.

     



  • Yeah; IIS is configured to force HTTPS on that page, and in addition the .ashx command double-checks anyway. Just in case it gets deployed on someone else's server at some point in the future.

    @mott555 said:

    I generate tokens using new GUIDs and then performing an SHA hash on them.

    I can't do that because I don't have server-side sessions. Or I would.


  • Trolleybus Mechanic

    @blakeyrat said:

    Here's how I've done it (disclaimer: I haven't read the other posts).
     

    So par for the course. =)

    Kidding aside, thanks for responding. I knew you'd done a bunch of API work, so I was looking forward to hearing your take on it.

    The long-term authentication will probably be a bit of overkill for this project. There really will only be the one 3rd party using it, and we're expecting at most a dozen to a couple hundred requests per month. Authing them each request won't be that strenuous. But I'll keep your technique in mind for another slightly more ambitious projecting coming down the pipe in the future.



  • It depends a bit on your use case, depnding on how public your public API is I would either use:

    • SSL/TLS with client certificates
    • SSL/TLS with digest authentication
    • SSL/TLS with a pre-shared key

    I would try to avoid putting the credentials in the URL or in the payload, too many ways to get them logged somewhere in plain text on your server.



  • #2 is bad for precisely the reasons you stated. Having to sort through unauthenticated data trying to find auth tokens is a disaster waiting to happen. There all well-known exploits for SSL and SSH due to the "work with data before authenticating it" design flaw. Don't do it. And if somebody goofs up and things get logged, that could suck.

    As already pointed-out, SSL is secure enough, you just need to authenticate. Now only if there was some way to authenticate an HTTP request..

    Seriously, use HTTP digest auth. It's simple: pretty much every HTTP library supports it (and even if they don't, there are tons of libraries that make it easy to calculate the digest yourself and slap it into an HTTP header). Your server supports it. In fact, your server probably supports several "backends" so you can validate the request using something as simple as a flat file (like htpasswd) or something more complex like LDAP, SQL, web service, etc. You can log every HTTP request and it won't matter because the password is securely hashed. No worrying about trying to strip out usernames/passwords from XML.

    Don't use basic auth (i.e. base64-encoded auth). SSL is secure enough (although the CA system is a huge security hole, but whatever..) but many implementations are broken enough that they might permit someone to connect to a server with an invalid cert. (Or, just as bad, developers using your API simply disable cert checks and then someone can man-in-the-middle the connection.) Then your dumb users are sending their password to a malicious attacker. If they're using digest, this won't matter because the password is hashed.

    While I'm on it: buy a real cert. They're cheap compared to the hassle of self-signed server certs. Doesn't matter who you buy from, they're all equally-secure, so just pick someone cheap with good customer service. Don't buy an EV cert, they're just marketing bullshit--no more secure than anything else. (EV certs are worthwhile on public-facing sites because most browsers make the address bar all green and fancy which makes your customers feel more secure. But as an actual security measure they're no better than the plain-old, $50 /year Godaddy cert.) Oh, and if you think you might want to secure multiple sites in the future, consider a wildcard cert or a multi-domain (sometimes called UCC or unified communications) cert.

    Don't mess with client certs. They're too much of a pain and support is minimal at best. Besides, they're no more secure than HTTP digest with a strong (i.e. long, randomly-generated) password.

    Don't try to roll-your-own. Somebody mentioned SOAP and if you're already doing it, then sure, use its auth mechanisms, but if you're not using an RPC layer with a built-in auth mechanism, just use HTTP digest.

    Oh, and disable SSL block ciphers on your server (except for AES GCM, assuming your server is up-to-date enough to support it..) There are exploits for SSL block ciphers out there.. very, very unlikely that anybody will find a way to exploit them, but better safe than sorry. So no AES (except the aforementioned, rarely-supported GCM); no 3DES (shouldn't be using this anyway).. just use RC4 and you'll be fine.



  • @morbiuswilters said:

    #2 is bad for precisely the reasons you stated. Having to sort through unauthenticated data trying to find auth tokens is a disaster waiting to happen. There all well-known exploits for SSL and SSH due to the "work with data before authenticating it" design flaw. Don't do it. And if somebody goofs up and things get logged, that could suck.

    As already pointed-out, SSL is secure enough, you just need to authenticate. Now only if there was some way to authenticate an HTTP request..

    Seriously, use HTTP digest auth. It's simple: pretty much every HTTP library supports it (and even if they don't, there are tons of libraries that make it easy to calculate the digest yourself and slap it into an HTTP header). Your server supports it. In fact, your server probably supports several "backends" so you can validate the request using something as simple as a flat file (like htpasswd) or something more complex like LDAP, SQL, web service, etc. You can log every HTTP request and it won't matter because the password is securely hashed. No worrying about trying to strip out usernames/passwords from XML.

    Don't use basic auth (i.e. base64-encoded auth). SSL is secure enough (although the CA system is a huge security hole, but whatever..) but many implementations are broken enough that they might permit someone to connect to a server with an invalid cert. (Or, just as bad, developers using your API simply disable cert checks and then someone can man-in-the-middle the connection.) Then your dumb users are sending their password to a malicious attacker. If they're using digest, this won't matter because the password is hashed.

    While I'm on it: buy a real cert. They're cheap compared to the hassle of self-signed server certs. Doesn't matter who you buy from, they're all equally-secure, so just pick someone cheap with good customer service. Don't buy an EV cert, they're just marketing bullshit--no more secure than anything else. (EV certs are worthwhile on public-facing sites because most browsers make the address bar all green and fancy which makes your customers feel more secure. But as an actual security measure they're no better than the plain-old, $50 /year Godaddy cert.) Oh, and if you think you might want to secure multiple sites in the future, consider a wildcard cert or a multi-domain (sometimes called UCC or unified communications) cert.

    Don't mess with client certs. They're too much of a pain and support is minimal at best. Besides, they're no more secure than HTTP digest with a strong (i.e. long, randomly-generated) password.

    Don't try to roll-your-own. Somebody mentioned SOAP and if you're already doing it, then sure, use its auth mechanisms, but if you're not using an RPC layer with a built-in auth mechanism, just use HTTP digest.

    Oh, and disable SSL block ciphers on your server (except for AES GCM, assuming your server is up-to-date enough to support it..) There are exploits for SSL block ciphers out there.. very, very unlikely that anybody will find a way to exploit them, but better safe than sorry. So no AES (except the aforementioned, rarely-supported GCM); no 3DES (shouldn't be using this anyway).. just use RC4 and you'll be fine.

    +numbers


  • Discourse touched me in a no-no place

    @morbiuswilters said:

    SSL is secure enough (although the CA system is a huge security hole, but whatever..) but many implementations are broken enough that they might permit someone to connect to a server with an invalid cert. (Or, just as bad, developers using your API simply disable cert checks and then someone can man-in-the-middle the connection.)

    The main problems with the CA system stem from the fact that it's hard to tell just how much the CAs should be trusted. If you're really paranoid and aren't using a browser but rather a custom client, use your own private CA and you'll be able to work out exactly how much to trust the CA. It's a bunch of hassle though, and doing it well requires acting like you're a soulless bureaucrat. Of course, if you want to act like a soulless bureaucrat, it's ideal.
    @morbiuswilters said:
    While I'm on it: buy a real cert. They're cheap compared to the hassle of self-signed server certs. Doesn't matter who you buy from, they're all equally-secure, so just pick someone cheap with good customer service. Don't buy an EV cert, they're just marketing bullshit--no more secure than anything else. (EV certs are worthwhile on public-facing sites because most browsers make the address bar all green and fancy which makes your customers feel more secure. But as an actual security measure they're no better than the plain-old, $50 /year Godaddy cert.) Oh, and if you think you might want to secure multiple sites in the future, consider a wildcard cert or a multi-domain (sometimes called UCC or unified communications) cert.

    The value of an EV certificate is purely bureaucratic. The issuers of EV certificates are supposed to do much more stringent checks that the described entity is for who it claims to be for than normal (which is silly; that's actually just the level of checking that was originally envisaged in the CA system). Usually they just check that the requestor is the administrative contact for the domain, often by sending the signed certificate to the admin contact by email.
    @morbiuswilters said:
    Don't mess with client certs. They're too much of a pain and support is minimal at best. Besides, they're no more secure than HTTP digest with a strong (i.e. long, randomly-generated) password.

    It's possible to make them work and do amazing things with them. But you really need to design your entire architecture around their use, and that's for serious experts. Hardly anyone needs that level of identity assurance.
    @morbiuswilters said:
    Don't try to roll-your-own. Somebody mentioned SOAP and if you're already doing it, then sure, use its auth mechanisms, but if you're not using an RPC layer with a built-in auth mechanism, just use HTTP digest.

    Also, avoid WS-Security and the stack of stinking shit built on top of it. You'll thank me.
    @morbiuswilters said:
    Oh, and disable SSL block ciphers on your server (except for AES GCM, assuming your server is up-to-date enough to support it..) There are exploits for SSL block ciphers out there.. very, very unlikely that anybody will find a way to exploit them, but better safe than sorry. So no AES (except the aforementioned, rarely-supported GCM); no 3DES (shouldn't be using this anyway).. just use RC4 and you'll be fine.
    If you're serious about it, make sure you use the recommended profiles for supported crypto algorithms (usually easy: just keep your HTTP server patched up to date).



  • If you're running on IIS you can use this handy tool to disable all the insecure block ciphers. Then use SSL Labs' testing tool to see how well your server is configured.

    For authentication, just use what's already available in the HTTP stack: WWW-Authenticate. Digest authentication will probably work just fine for you, and is easily understood by whatever system is going to communicate with your API. If you don't want clients to submit username+password combinations, you might want to consider implementing API keys which are sent along with your request (for examply, by using a custom header). The advantage of API keys is that they can be revoked by the account owner or the support desk when needed, the disadvantage is that it needs more time to implement this and that it is a potential attack vector (it depends on how guessable your API keys are).



  • @Alex Media said:

    If you're running on IIS you can use this handy tool to disable all the insecure block ciphers. Then use SSL Labs' testing tool to see how well your server is configured.

    For authentication, just use what's already available in the HTTP stack: WWW-Authenticate. Digest authentication will probably work just fine for you, and is easily understood by whatever system is going to communicate with your API. If you don't want clients to submit username+password combinations, you might want to consider implementing API keys which are sent along with your request (for examply, by using a custom header). The advantage of API keys is that they can be revoked by the account owner or the support desk when needed, the disadvantage is that it needs more time to implement this and that it is a potential attack vector (it depends on how guessable your API keys are).

    wow necro



  • @Nagesh said:

    wow necro
     

    such undead

                                      very lich



  • @dhromed said:

    @Nagesh said:

    wow necro
     

    such undead

                                      very lich


    much Trahearne


    so Zhaitan



  • @Ben L. said:

    much Trahearne


    so Zhaitan

    Uh! I guess nobody told you, but Elder Scrolls Online is out now!!! UUUH!!!! HELLO!!!!



  • @blakeyrat said:

    @Ben L. said:
    much Trahearne


    so Zhaitan

    Uh! I guess nobody told you, but Elder Scrolls Online is out now!!! UUUH!!!! HELLO!!!!


    many cost


    so subscription


    much pay



  • @Ben L. said:

    @blakeyrat said:
    @Ben L. said:
    much Trahearne


    so Zhaitan

    Uh! I guess nobody told you, but Elder Scrolls Online is out now!!! UUUH!!!! HELLO!!!!


    many cost


    so subscription


    much pay

    I was largely underwhelmed by the beta. Pass.



  • I was too, and yet I bought it anyway because I am a consumer whore.



  • @blakeyrat said:

    I am a consumer whore.
    I believe whores are considered suppliers, not consumers.



  • @blakeyrat said:

    My API has a call that specifically does authentication-- the caller uses it, passes in their user/pass (over SSL of course), the API checks this and returns to them a token. The token consists if: the user's username, password, the max date they're authenticated until (an hour, unless they checked "keep me logged in", in which case it's 2 weeks), and some other basic info (for example, what client they belong to, whether they're an administrator for that client.)

    Including the password in the token sounds like a bad idea. It also seems unnecessary.

    And you don't say anything about MAC. Are you using an AES mode with built-in MAC?



  • @pjt33 said:

    @blakeyrat said:
    My API has a call that specifically does authentication-- the caller uses it, passes in their user/pass (over SSL of course), the API checks this and returns to them a token. The token consists if: the user's username, password, the max date they're authenticated until (an hour, unless they checked "keep me logged in", in which case it's 2 weeks), and some other basic info (for example, what client they belong to, whether they're an administrator for that client.)

    Including the password in the token sounds like a bad idea. It also seems unnecessary.

    And you don't say anything about MAC. Are you using an AES mode with built-in MAC?


    Any other idea? Please put them in my thread!

  • Discourse touched me in a no-no place

    @pjt33 said:

    Including the password in the token sounds like a bad idea. It also seems unnecessary.

    And you don't say anything about MAC. Are you using an AES mode with built-in MAC?

    If you're sending the token back to the originating service, you don't need any of that shit. Just a very-hard-to-guess nonce (that you use as a database key to look up who you are and when your session expires). If you're handing the token off to someone else, you should digitally sign it (so that others can know who issued it) and you should put only minimal other information in. Usually you're talking about giving just an ID, who issued the ID, and where the user thought he was logged into when it was issued. Everything else you look up by asking the issuer service. (This is the core of how OpenID and Shibboleth work.) Getting all of this right when you start having services delegating actions to other services is very tricky.

Log in to reply