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.
Labels:

Comments

Post a Comment

Popular posts from this blog

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 a...
Post a Comment
Read more

SQL, Booleans, JPA, and Hibernate

For a long time, SQL and Booleans have not gotten along.  Standards for SQL never really addressed the need for boolean data -- it was assumed that some other data type could easily just step in and address this need.  The result was a lot of different data models for boolean values.  Here are some examples. TRUE or FALSE T or F Y or N 1 or 0 <any value> vs NULL The internet shows the debate has gone on , even as SQL standards have changed .  Coming from a professional background with Oracle, I struggled with this across my teams because everyone had a different opinion, which led to a lot of time wasted due to debate. This said, I appreciate working with native queries in hibernate's JPA implementation against MySQL.  MySQL supports a BIT data type I recently discussed .  When we represent data in MySQL with BIT and restrict the length to just 1 (ie 1 bit), Hibernate JPA magically knows to query and return this data as a Boolean in the ...
Post a Comment
Read more

ANSI-92 SQL Syntax - aka "JOIN" me in software progress!

 I've run into several projects lately that don't use and/or refuse to use the JOIN keyword/syntax.  I've had conversations in these projects to help people understand that, but I wonder why this is not more common across SQL database projects.  This standard is not new, and it more easily defines the join section vs the WHERE/filter section, so it has good benefits.  So far, the only reason I have heard to not use it is "we just don't tend to do that here."  This makes me sad. I hope to continue evangelizing small changes like this in my projects, be it JOIN, use of functional programming, listening to IDE feedback (great static analysis checking... available before you ever even push!), etc.  There are so many small things that help make software easier for everyone, I think.
Post a Comment
Read more