Skip to main content

OAuth...is vague

I've recently been working on a project to integrate with a 3rd party.  This is normal work in software development; we constantly work to make this system talk to that system and so on.  The web has made this a lot easier, as many groups are moving their APIs to a more standard kind of setup.  REST is ruling the integration world right now (as far as I can tell), and I don't see that changing any time soon.

Security... is a different matter.  Authorization and authentication tools keep evolving, sometimes in sync with integration... and sometimes not.  Spring is currently pushing out new and shiny updates to spring boot (2.1.0 just came out!), but spring security has not necessarily been keeping up.  This isn't unique to spring.  The 3rd party integration I'm working on is still using OAuth1.0 (NOT 1.0a if I can believe the documentation).  When I saw that, I am sad to say that I was not surprised.

Sparing the debate of OAuth1.0a vs OAuth2.0 and the comparison of OAuth to other options like JWT, I find two things frustrating:

  1. Security always seems to take a back seat... which leads to problems.  Feature work is important, I know.  It keeps the lights on.  But in a world where data leaks are regular news, I fear for this continuous cycle of security falling behind.
  2. Documentation for OAuth is vague.  Many places that claim to document OAuth are for OAuth 2.0, but they don't say 2.0.  I can understand that older documentation referencing OAuth 1.0 would just say 'OAuth' because 2.0 hadn't come out yet.  What makes this worse is the weirdly different nature of OAuth 1.0(a) vs 2.0.  I'm not a security expert at all, but I see over and over again that 1.0(a) and 2.0 are nothing alike, so it is super frustrating to keep digging for documentation on 1.0(a), and I won't know whether what I am reading is referencing one or the other.  So much of what the documentation on OAuth has to say is #toovague.

Comments

Popular posts from this blog

JHipster, Liquibase, MySQL, and initializing data, including booleans!

When generating a data model from JHipster JDL, we will often declare entities with Boolean fields.  I have so far abandoned H2 as a database because of liquibase issues, and both my dev and production databases will be MySQL.  This is relevant to the Boolean field desire there is a long history in software development of how to store Boolean data types in a SQL database whose standards classically do not support Boolean. In the current JHipster/Liquibase incarnation, tables in MySQL are generated for us, which is really nice.  The Boolean data types are stored as BIT  (1).  This is not a problem so far -- most developers seem to agree now that as a best practice, we should store values in databases as false = 0 and true = 1, and a BIT(1) is a great, simple way to do that. An issue arises when we try to use liquibase to set/update our database to the desired starting state.  For my project, I've chosen gradle instead of maven as a build tool, and gradle has a plugin for liquiba

Spring Security - Authority vs Role

I have spent a lot of time recently trying to understand the difference between Authority and Role in Spring Security.  This is a brief review of what I found. When creating a UserDetailsService or overriding configure(AuthenticationManagerBuilder auth) in the security config class that extends WebSecurityConfigurerAdapter, I basically get complete control over what I populate inside of the UserDetails that is used/returned.  This is important because the UserDetails interface really only cares about how to return one thing: Collection<? extends GrantedAuthority> getAuthorities(); A GrantedAuthority just seems like a glorified String wrapper that names some thing.  The question is... what is that thing? This is where the subtle difference between Authority and Role comes into play. I think that Role is an older thought/construct that automatically gets plugged into Authority if we just create a user with a Role.  But completely forget about the code and classes for a mi

Gmail internal application, Two-Legged OAuth2, Server to Server authentication, and Google API versions

I am working on a little tool at home in my free time to put some skills into practice.  The general idea (nothing novel) is this: I have some financial alerts sent to a new email address I have spun up on my domain.  I am creating an AWS Lambda that will wake up on an hourly schedule, read those emails, and publish SNS messages with parsed financial transaction information.  I then will have an SQS queue listen to the SNS message topic that is consumed by a Step Function.  The Step Function will: store the financial transaction information into a database send an SMS to me if the transaction is above a certain threshold. I could later extend this to do some aggregation reporting, etc if I wanted, too.  This will only work for my own financial transactions, and the data being gathered/stored will be sufficiently vague, so I am not really concerned about financial security for this project. The biggest hurdle I have run into so far is connecting to Gmail securely.  I was ab